Every instruction a bank agent receives should carry its source, and the source should decide what the instruction may authorise. A request made in an authenticated app session can change a standing order. The same words in an email cannot. A note from another agent carries no more authority than the instruction behind it. Without provenance on each instruction, an agent cannot tell which of these it is looking at.
Why do instructions need provenance, not just facts?
Facts tell an agent what is true. Instructions tell it what to do. In a bank, instructions are where fraud and error concentrate, because an instruction is the thing that moves money, changes details or grants access.
An instruction has an author, a channel and a level of verification. All three matter. "Pay 2,000 to this account" from a customer who has just passed strong authentication is a valid instruction. The same sentence in an email that looks like it is from the customer is a claim that someone wants a payment made. The agent reads identical words. The bank must treat them completely differently.
The general case for provenance travelling with every fact applies with extra force to instructions, because an instruction stripped of its source looks exactly like an authorised one.
Where do bank instructions come from?
Banks receive instructions through many channels, and each establishes a different level of trust. A practical mapping, using the four provenance classes, looks like this.
| Channel | Typical class | What it may authorise on its own |
|---|---|---|
| Authenticated app or online banking session, with strong customer authentication | Declared, by a verified customer | Routine changes and payments within the customer's own limits |
| Branch, with identity checked in person | Declared, by a verified customer | As above, plus some changes that need identity evidence |
| Phone, with knowledge-based checks | Declared, at lower assurance | Information and low-risk changes; payments and payee changes need step-up |
| Email or letter, unauthenticated | External | Nothing on its own; it starts a verification process |
| Approved internal system, such as the fee engine or a signed policy table | Sealed or signed | The actions that system is authorised to drive |
| Staff member through a controlled workflow | Signed, by an accountable person | Actions within that person's own mandate |
| Another agent | Inherits the class of the instruction it is acting on | No more than the original instruction could authorise |
The last row is where most hidden risk lies. In a multi-agent setup, an instruction can pass through several agents before reaching the one that acts. If each hop drops the source, the final agent sees a clean instruction from a trusted internal caller. The original email has been laundered into an internal request.
How does this play out on a simple refund?
Consider refunds of bank charges, a common early agent use. The question of whether an AI agent can refund bank charges depends heavily on where the request came from.
A customer asks in an authenticated chat for an overdraft fee to be refunded, citing a delayed salary payment. The instruction is declared by a verified customer. The fee record is sealed by the fee engine. The refund policy is signed by its owner. If the request fits the policy and the customer's limits, a certified agent may refund at depth 3.
The same request by unauthenticated email asks for the refund to be paid to a different account. The instruction is external. The destination is external. The agent can log the request, check the fee record, and draft a reply asking the customer to confirm through the app. It cannot refund to a new account on the strength of the email, however plausible.
How should a bank set this up?
- Stamp at the channel. Each channel stamps instructions with their class and the level of authentication achieved, before any agent sees them.
- Map classes to actions. For each capability, record which instruction classes may authorise it. Write this into the bounds the platform enforces, not into prompts.
- Carry the class through hand-offs. When an agent passes work to another, the original instruction's class goes with it. An agent can never upgrade a class.
- Step up, not around. When an instruction's class is too weak for the action, the agent asks the customer to confirm through a stronger channel. It does not look for a reason to proceed.
- File the class with the verdict. Every action records the instruction's source and class, so a disputed action can be traced to its origin.
Does this touch model risk?
Partly. An agent that interprets instructions and decides what they mean is doing something a bank's model risk framework may want to cover, a question explored in whether an AI agent is a model under bank model risk rules. Provenance reduces the risk the framework has to carry, because the decision about what an instruction may authorise is made by rules, not by the agent's interpretation.
Where Pryme fits
The Pryme Context Protocol stamps every instruction and fact with its provenance class at the point it enters, and the class travels with it across agents. The minimum chain checks the class against the action at the moment it runs. An external claim cannot authorise a payment, and no agent can raise the class of an instruction it received. See AI agents in banking: what they may and may not do.
Questions people ask
Is a phone instruction enough for a payment?
It depends on the bank's authentication on the call. Knowledge-based checks alone are often not strong enough for payments or payee changes, so the agent should step up to a stronger channel.
What about instructions from a power of attorney or third party?
Treat them as declared by the third party, once their authority is verified and recorded. The agent should check that the specific instruction falls within the scope of that authority.
Can staff override an instruction's class?
A staff member can verify an instruction through a stronger channel and record that verification. That adds a new, stronger fact; it does not rewrite the original instruction's class.