Payout agent

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.

How the queue works

The agent decides within your limits. A person decides above them.

What is queued

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.

What the approver sees

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.

Who may decide

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.

What a decision proves

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.

What happens next

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.

Deadlines and reminders

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/run with your policy_id and key queues each held payout.
  • GET /api/v1/approvals?status=pending lists them.
  • POST /api/v1/approvals/{id}/decision records the approval or rejection.
  • The approval_status MCP tool tells an agent whether it may proceed.