Approval queue
The payouts your agent held for sign-off under your own approval limits, with the facts to decide on. Approve or reject each one; every decision is signed and chained to the agent's decision record.
The agent decides within your limits. A person decides above them.
Only a payout the agent may not release alone: above the agent's own limit and within the approval tier of your policy. Payouts within the agent's limit are released without a queue item; payouts above the approval limit are blocked and never queued.
The pair and amount, the beneficiary as the instruction names them (never an account number), the selected route with its cost against the reference, the release-by date, the limits that held it and the decision record it came from.
Only the role your policy names for agent releases in the approval tier. A decision by any other role is refused. A rejection needs its reason, which is returned to the agent.
Each decision is hashed onto the agent's decision record and signed, so the record reads in order: what the agent decided, then who signed it off, when and why.
An approved payout carries the sign-off the release record asks for, so the agent records the release against your policy with it. SwapEazi moves no money: your own provider executes the payment.
An item undecided after its release-by date is marked expired and is not released by the agent. With an approver email on your policy, the approver is written to when an item is queued and once more a banking day before its release-by date.
Your systems use the same queue through the API:
POST /api/v1/agent/runwith your policy_id and key queues each held payout.GET /api/v1/approvals?status=pendinglists them.POST /api/v1/approvals/{id}/decisionrecords the approval or rejection.- The
approval_statusMCP tool tells an agent whether it may proceed.