How to connect an AI agent to your order management system

Treat each order type as its own capability. The agent reads orders, drafts new ones for the customer to confirm, and may amend or cancel future-dated orders before cut-off within bounds. Creating an order to a new payee, releasing an order for execution, and placing buy or sell instructions are held for a named person or staged for release.

What does the connection involve, and who owns it?

In a bank, an order management system holds instructions waiting to be carried out: standing orders, future-dated and scheduled payments, and in investment or treasury settings, buy and sell orders. An instruction in the system is a promise to move money later. Changing it changes when, how much and to whom.

That makes the system a natural place for agents to help customers ("move my rent payment to the 3rd") and a sensitive one to connect. The payments or operations owner for each order type approves its capabilities. Fraud owns the rules on new payees. Where orders are investment or treasury instructions, the desk head owns them. The wider frame is in our guide to AI agents in banking.

Which permissions should you grant, and at what depth?

Whether an agent should set up recurring payments for customers is answered in whether an AI agent can set up a direct debit or standing order.

How do you connect it, step by step?

1. Person, order type owners: approve capabilities per order type. Customer payment orders and treasury orders are separate decisions. Evidence: approved list per type.
2. Integration team: builds one route per capability per order type. "Amend customer standing order date" is not the same route as "amend treasury order". Evidence: route list.
3. Integration team: gives the agent its own identity. Evidence: identity and grants.
4. Person, fraud: sets rules for new payees and changes. New payee, changed account details, amount increase above a set size, many changes in a short period. Evidence: rules as versioned bounds.
5. Platform, on each call: checks bounds. Capability in scope, certificate in date, cut-off not passed, payee source signed, customer's limits held, customer authenticated where the change requires it. Evidence: verdict per call.
6. Agent, at its certified depth: handles requests. Every change is confirmed back to the customer in plain words: what changed, from what, to what, from when. Evidence: confirmation sent.
7. Person, named approver or dealer: decides held and staged items. Evidence: decision and identity.
8. Integration team: wires revocation per capability and order type. Evidence: drill results.

Which controls matter, and what is recorded?

Cut-off is a bound. After cut-off, an amendment may not take effect or may need a recall. The agent must say so, not attempt it. Evidence: refused verdicts naming the cut-off.

Strong customer authentication where required. In the EU, PSD2 requires strong customer authentication for many payment instructions; the agent cannot complete it on the customer's behalf. Evidence: authentication result linked to each confirmed order.

New payees held. Evidence: held verdicts with the fraud rule.

Before-and-after record. Every amendment stores the old and new values. Evidence: change history per order.

Staged investment orders. The agent prepares; an authorised person releases. Evidence: staged order and release identity.

Duplicate detection. A customer who asks twice in one conversation, or on two channels, should get one change, not two. Evidence: duplicate requests linked and refused.

Model risk where the agent proposes. If the agent suggests orders from its own analysis, such as rebalancing or cash sweeps, many banks will treat that logic as a model under model risk management, with validation and an owner. Evidence: model inventory entry.

What should you measure?

• Amendments per day, and the share reversed by customers afterwards, tracked as a count.
• Missed payments caused by agent changes.
• Held new-payee orders confirmed as fraud attempts.
• Requests refused for cut-off, which shows whether customers are being told the right times.
• Staged orders released unchanged, against those edited by the dealer.

Where does it usually go wrong?

Order types share one route. A connection built for customer standing orders is reused for treasury orders, with the same depth.

Amendments hide payee changes. An "amend" route lets the agent change the account number as well as the date. Split payee fields into their own capability.

Silent cancellation. The agent cancels a duplicate-looking order the customer wanted. Cancel only on request.

Confirmations are vague. "Your payment has been updated" does not tell the customer what changed. State the before and after.

Treasury is treated like retail. Treasury orders carry market and liquidity risk that customer orders do not; see connecting an agent to your treasury management system. Card instructions have different risks again, covered in connecting an agent to your card management system.