Bill Pay & Transfer Agent
A user states a financial goal in everyday Iraqi Arabic. One orchestrator plans it, specialist agents carry it out, and a verification layer confirms the action matches the request — before any money moves.
A single financial intention costs a dozen steps.
Paying a bill or sending money is one thought for the user and a chain of disconnected systems for everyone else.
Fragmented rails
Bills, wallets, bank transfers and merchant accounts each live in a separate app with its own flow and identifiers.
Language mismatch
Interfaces expect formal Arabic or English menus. People speak Iraqi dialect, half-sentences, and voice notes.
Manual context
The user re-supplies the same recipient, account and amount details to every channel, every time.
Late risk checks
Fraud and KYC problems surface after the transfer, in a support ticket — not before the decision.
One platform. Many agents. One accountable decision path.
This is not six disconnected AI features. It is one autonomous financial operating system whose agents collaborate to complete financial goals safely. One user goal → one orchestrator → multiple specialist agents → verified action.
Central orchestrator
A supervisor agent turns a stated goal into a plan and owns the outcome end to end.
Specialist agents
Narrow, testable agents for payment, fraud, KYC, verification, lending, merchants and support.
Shared memory & tools
One context store and one governed tool layer, so every agent sees the same facts and calls the same rails.
Permission boundaries
Autonomy is explicit: what an agent may do alone, what needs confirmation, what is blocked.
Bill Pay & Transfer Agent
The one workflow we build deeply, instrument, and evaluate against a held-out test set.
حول ٥٠ ألف لحيدر.
→ intent: transfer · recipient ambiguous
Known contact, low amount. Agent resolves the recipient, confirms the match, executes.
ادفع فاتورة الكهرباء.
→ intent: bill_pay · biller known
Pulls the outstanding amount, checks the due date, presents it for a one-tap confirmation.
دزّيت فلوس بس ما وصلت.
→ intent: support · transaction trace
Not a new payment. Routed to trace the prior transfer and its settlement state.
What the agent owns
Understanding the goal, resolving recipient and biller, completing missing fields, preparing the transaction, executing against the payment tool, and confirming the result.
What it must never do
Move money on an unresolved recipient, skip the confirmation gate above the risk threshold, or report success it has not verified.
What "done" means
The executed transaction matches the user's stated goal on every field, the user was shown what they approved, and the result was read back from the rail.
Supervisor, JEV, and specialist agents.
Every request descends the same path. What changes is how far down it needs to go.
A lightweight pass that decides how much machinery a request actually needs, so trivial requests never pay for a full reasoning pipeline. It answers, cheaply:
Builds the plan, selects agents dynamically, sequences their calls, resolves conflicting outputs, holds the confirmation gate, and owns recovery when a step fails.
JEV is the routing layer's name in this architecture; it is described here by function only, so the internal definition stays authoritative.
A high-value transfer, in full.
حوّل مليون دينار لهذا الحساب.
“Transfer one million dinars to this account.”
Intent is a transfer, the amount is above the risk threshold, and the recipient is not a known contact. Routes to the supervisor with a full-pipeline flag.
Payment → Fraud → KYC → Verification → confirmation gate → execution.
Resolves the account, checks balance and limits, assembles amount, currency, recipient and reference. Flags that the recipient is new.
New recipient, high value, first-time pattern. Elevated but not blocking — returns the reasons, not just a score.
Confirms the user's verification tier permits this amount. If not, it returns exactly which requirement is missing.
Compares the prepared transaction field by field against what the user actually said. Any mismatch stops the chain here.
The user is shown the recipient, amount and fraud reasoning in Iraqi Arabic and must approve. No approval, no execution.
Idempotent call with a request key, so a retry can never produce a second transfer.
Reads the settled state back from the rail and reports it. On timeout it checks status before retrying; on failure it explains the cause and offers the next step.
The same chain contracts for low-risk requests: a 10,000 IQD transfer to a saved contact skips fraud escalation and the confirmation gate, and executes in one hop.
One architecture, six financial domains.
All six run on the same supervisor, the same memory, and the same tool layer. One is built and evaluated for this hackathon; the rest prove the expansion path.
Bill Pay & Transfer Agent
Understands the goal in dialect, prepares and verifies the transaction, executes under permission control, and recovers from failure.
Fraud & Scam Protection
Detects scam patterns, OTP-sharing pressure, unusual recipients and out-of-profile transaction behaviour.
KYC Document Agent
Reads submitted identity documents, checks completeness against tier requirements, and names what is missing.
SME & Merchant Assistant
Cash-flow questions, settlement summaries and business-level financial analysis for merchants.
AI Loan Officer
Collects and structures application data, detects missing requirements, and prepares a reviewable file.
Support Pipeline Automation
Categorizes the problem, diagnoses common cases, drafts the resolution, and escalates with full context.
Agentic, not conversational.
The system does not answer a question and stop. It runs a loop until the goal is complete, blocked, or escalated.
The AI acts on its own to…
understand goals · create plans · choose agents · retrieve information · call tools · validate data · detect its own failures · retry safe, idempotent operations · route and escalate cases · verify results.
It stops and asks when…
the action moves money above a threshold · the recipient is new or ambiguous · the operation is irreversible · fraud or KYC signals are elevated · agents disagree · the user's intent has more than one plausible reading.
Autonomy with explicit permission boundaries.
Autonomy is a property of each action, not of the system as a whole. Nothing irreversible happens without an authorization path.
| Action | Autonomy level | Control |
|---|---|---|
| Read balance, bills, history | Fully autonomous | Logged in the decision trace |
| Resolve recipient or biller | Autonomous, verified | Match shown back to the user |
| Prepare a transaction | Autonomous | Nothing executes at this stage |
| Low-value transfer, saved recipient | Autonomous within limits | Per-user limits and daily caps |
| High-value or new-recipient transfer | Requires confirmation | Explicit user approval before execution |
| Elevated fraud signal | Held | Reasons shown; user may confirm or abandon |
| KYC requirement unmet | Blocked | Missing requirement named; routed to KYC flow |
| Suspected scam pattern (OTP, coercion) | Blocked | Warned and escalated, not executed |
| Irreversible or out-of-policy operation | Human review | Escalated with full context |
هذا الرقم ديتصل بيّ ويگلي انطيه رمز الـOTP.
→ fraud agent · block + educate
Recognized as an OTP-sharing scam. The system never assists the request, warns the user, and escalates.
Decision trace
Every request stores which agents ran, what each returned, why the route was chosen, and what the user approved — reviewable after the fact.
Idempotent execution
Payment calls carry a request key. Retries after a timeout reconcile against the rail instead of issuing a second transfer.
Designed around the cases that actually occur.
| Failure | System response |
|---|---|
| Ambiguous request | Asks one targeted clarifying question instead of guessing — never resolves ambiguity by assumption on a payment. |
| Wrong or unresolved recipient | Presents candidate matches with distinguishing detail; requires selection before preparing the transaction. |
| Missing payment information | Names the specific missing field and requests only that, preserving everything already gathered. |
| Suspected scam | Blocks, explains the pattern in the user's dialect, and escalates rather than completing the action. |
| Insufficient KYC | Stops before execution, states the exact unmet requirement, and hands off to the KYC flow. |
| Payment API unavailable | Reports honestly, offers to retry, and never reports a success it could not confirm. |
| Duplicate transaction | Detected by request key and recent-transaction check; surfaced to the user instead of executed twice. |
| Conflicting agent decisions | Supervisor applies precedence — safety agents override convenience — and escalates when the conflict is unresolvable. |
| Tool timeout | Status is reconciled before any retry; ambiguous outcomes escalate rather than repeat. |
| Unsupported request | Declines clearly and routes to the correct channel instead of improvising a partial action. |
How we will prove it works.
The metrics below are targets to measure, not results already achieved. Scores will be reported against a held-out test set the system does not see during development.
| Metric to measure | What it tells us |
|---|---|
| Intent routing accuracy | JEV sends the request down the right path. |
| Correct agent selection | The supervisor picks the right agents — and no unnecessary ones. |
| Task completion rate | Stated goals that reach a correct terminal state. |
| Transaction information accuracy | Amount, recipient, biller and reference are exactly right. |
| Iraqi Arabic understanding accuracy | Dialect, slang and half-sentences are parsed as intended. |
| Fraud detection rate | Seeded scam cases caught before execution. |
| Unsafe-action blocking rate | Actions that should never execute, never execute. |
| False-positive rate | Legitimate requests not wrongly blocked or escalated. |
| Tool-call success rate | Well-formed calls and correct handling of tool errors. |
| Escalation accuracy | Cases escalate when they should — and only then. |
| End-to-end success rate | Goal to verified result, measured on unseen cases. |
Held-out test set
A set of Iraqi Arabic financial requests — including adversarial, ambiguous and scam cases — written separately and withheld during development. Reported numbers come from this set, not from examples the system was tuned on.
Synthetic data, no real customers
All development and testing runs on generated data. No real customer financial data is required.
What we build now, and what comes next.
Bill Pay & Transfer, built deeply
- Iraqi Arabic intent understanding for payments and transfers
- JEV routing and supervisor planning
- Payment, Fraud, KYC and Verification agents in the live chain
- Confirmation gates and blocked-action rules
- Failure recovery, retries and escalation
- Measured against the held-out test set
The remaining agents
- SME, Loan and Support agents are specified against the same architecture
- They reuse the supervisor, JEV layer, shared memory and tool layer unchanged
- Adding a domain means adding an agent and its tools — not a new system
- Each new agent inherits the same safety and permission controls
We deeply build and evaluate the payment and transfer workflow first. The remaining agents share the same architecture and demonstrate the platform's expansion path.
Financial software in Iraq should understand how Iraqis actually speak, and act on what they actually mean — safely, and end to end. We are building the autonomous layer that does it: one goal, one orchestrator, many agents, one verified action.