In financial services the expensive part is rarely detection. It is disposition: someone says yes or no, writes down why, and stands behind it two years later. Detection was industrialised twenty years ago. Disposition is still six logins and a free-text narrative.
What one alert actually costs
Take a correspondent banking alert on an outbound payment. Disposing of it means the payment system, onboarding for beneficial ownership, case management for how the prior alerts closed, screening for the list version behind the hit, core banking, and a certificate of incorporation as a PDF on a shared drive. Six systems, four identifiers for one legal entity, none a foreign key to any other.
Every field exists, is correct, and is owned by someone. What does not exist anywhere is the join, so an analyst performs it by hand and the reasoning lands in a narrative field nobody can query.
Why an agent guesses here
Point a model at those tables and it writes the join itself. The query is different on Tuesday, with nothing fixed to hand a validator. That is the disqualifying part here, not the fluency. No column tells a model which of the four identifiers is one legal entity, or that a screening hit is decided about rather than counted.
What gets declared, in order
Name the decisions first, in the words of the person who signs them. Close or escalate this alert. Accept, refer or investigate this claim. Then the purposes, because the purpose and not the job title decides what someone may lawfully see: a validator gets the model inputs, not the customer’s name. Each purpose is a database role with column-level grants, so a read outside it fails as a database error.
Only then the entities those decisions turn on, usually under twenty, and the links between them, where the questions actually live. Then the rules, each with a code that survives into the decision record: “activity inconsistent with profile” is a narrative, that code with the values that fired it is a fact you can test. Actions last. Every property binds to a real table and column in a source, which kills the elegant model of a bank whose data does not support it.
What the agent can do then
Give the same model that ontology and it stops inventing the join. It reads payments, onboarding, case management and screening where they sit, under the purpose the analyst is acting under, and answers in the unit’s own vocabulary with the rule that fired underneath it. A model may route: working out which decision is being asked for is genuinely hard. It must not compute: the join, the filter and the rule evaluation run in declared code, so a validator reviews the contract once, not a query regenerated on every run.
Nothing is written without approval
The disposition is a write: a status, a rationale, sometimes a block on an account. In Monarch it never executes because a model concluded something. A declared action persists as a pending approval, computes a real dry-run diff, and holds until a person commits or discards it. Where core banking cannot be written to, the output is a decision record a human carries across.
Replay is what a validator wants and a log will not give. The record stores its parameters and an immutable issued record: verdict, rules fired, codes, scope, a hash. Reopening it re-derives the decision under today’s permissions with no model call and flags divergence. That flag is four different investigations: the data changed, the rule changed, the binding changed, or the asker’s scope narrowed. It also answers the AI Act’s right to a meaningful explanation, because the rule identifier, the values that triggered it and where each came from are already in the record.
Two honest boundaries. This makes tampering evident, not impossible. And it is the wrong tool where the decision does not cross systems, where the value is a score at authorisation latency, or where nobody will own the ontology. Declare the decisions before the data, keep the model out of the correctness path, and make every decision re-derivable, including the ones that no longer reproduce.