They know which processor status means a payment is stuck. They know a particular counterparty routinely settles a day later than the agreement says, and when that delay matters. They know which fee difference is harmless, which one points to a broken configuration, and who has to get involved before it gets expensive. They know the policy says one thing, the operating procedure says another, and the exception has been handled the same way for three years.
Institutions call this tribal knowledge and usually treat it as a weakness to be written down someday. As agents move into operational work, it becomes something more specific: the operating context the agent does not have. Cordant is built to capture it as an operating map, a record of how the operation actually behaves that grows each time the team resolves an exception.
The documents and the data together still do not describe the whole operation
Financial institutions have plenty of documentation: contracts, policies, network rules, operating procedures, configuration files, case histories, approval matrices. They have plenty of data too: transactions, settlements, balances, fees, cases and logs.
And yet when something goes wrong, the answer often still starts with "Ask Sarah. She knows how this works."
Take a settlement. The contract says it should arrive within two business days. The processor shows when settlement was initiated. The bank statement shows when the money arrived. The case system shows that someone investigated the delay. None of those systems knows that this counterparty has missed the two-day term repeatedly, that operations tolerates one extra day under a specific condition, and that anything beyond that goes to treasury. A person knows, because they have seen it before.
An agent can read the same systems that person reads. It does not inherit what the institution learned between them.
Operators learn how the operation works by resolving its exceptions
Nobody sat down and wrote most of this knowledge. It accumulated one exception at a time. A settlement was missed and someone worked out why. A fee was wrong and someone found the amendment that explained it. A counterparty sent an unfamiliar status and someone learned it meant something different in practice from what the integration guide said. A control failed and someone traced the sequence of systems that caused it.
Each resolution taught the institution something about how its operation actually works. Then the case closed, and the lesson stayed with the person who solved it.
Software cannot interview an experienced operator and download twenty years of judgment. What it can now do is keep far more of what the institution learns while the work is happening.
Record each exception with its rule and its resolution
The useful unit of that knowledge is not a paragraph typed into a knowledge base. It is three things kept together:
- What should have happened: the contract, policy, network rule, fee schedule or operating procedure that governs the event.
- What actually happened: the records across the processor, bank, ledger, compliance system, case manager and every other system involved.
- What the institution learned from the difference: the cause, the resolution, who approved it and any rule the team now follows because it handled the exception.
Keep those together across enough exceptions and the institution has something no single system holds: an operating map. It is not an org chart, or a process diagram drawn during a consulting project and refreshed three years later. It shows how money, rules, systems, counterparties and decisions actually interact, and it changes each time the team resolves another exception.
An agent needs the operating map as much as it needs a capable model
Most discussion of AI in the enterprise is about the model: which one reasons better, which has the longest context window, which agent framework to use. Those questions matter. Inside a financial operation, the model is rarely the hardest part. The hard part is telling the agent what the institution means by correct.
Picture an agent investigating a settlement exception. It can see that the processor says settled, that the bank has not received the funds, and that the agreement says settlement is due within two business days. That is useful. The experienced operator also knows that this counterparty routes through an intermediary bank, that its Friday settlements regularly arrive on Monday, and that escalation is only required once the next processing window closes.
Without that context the agent can guess, escalate everything or hand the case back to a person, and none of those saves the team much work. The model is capable. What it is missing is the operating context.
Cordant builds the rule set and the operating map from the work itself
Cordant connects to the systems that already record what happened and to the agreements and policies that describe what should have happened, and it compares the two continuously. Where they diverge, it reconstructs what happened across every system involved, names the cause the evidence supports and routes the exception into the workflow where the team already handles it. The resolution then becomes context for the next time the same exception occurs.
Over time that produces two things most institutions do not have today:
- A rule set: the terms, policies and requirements that govern how the operation should behave, each tied to the document it came from.
- An operating map: how systems, counterparties, approvals, timing and exceptions actually behave in practice.
The rule set describes the operation the institution expects. The operating map describes the one it actually runs. Together they give people and agents the context to understand the difference and act on it. Cordant moves no money and replaces none of the systems it reads, and the decision stays with the operator.
What your institution learns about its own operation is the advantage that grows
Models will keep improving and every institution will have access to them. What stays specific to each institution is what it has learned about its own operation: which agreement governs which flow, which system can be trusted for which fact, which counterparty behavior is normal, which exception needs escalation, which sequence of events usually comes before a failure, and which resolution worked last time.
That knowledge is created every day. Most of it disappears into closed cases and the memory of the people who closed them.
Find out where the lessons from last month's exceptions live
Take the last ten exceptions your team closed. For each one, ask where the lesson now lives: in a rule a system checks, in a procedure someone updated, or only in the head of the person who resolved it. Count the ones in the last group. That count is the part of your operation an agent cannot see, and the part that leaves when an experienced operator does.
The institutions that get agents into operational work will be the ones that kept what their operators learned, not only the ones that picked the best model.
Money already moves in real time. The decisions should too.
