When a data consolidation project finishes, someone still has to open the result, notice a number is wrong and work out why. The project changed where the data sits. It did not change who does the work.
That does not make the project a bad investment. Pulling records together across a core banking system, multiple ledgers and a card processor is hard engineering. The teams doing it are good at their jobs, and the consolidated view is worth having.
The gap is between what the project delivers and what the operator actually needs. Ask an operator what they need and the answer usually comes in four parts:
- What is happening?
- Why is it wrong?
- What should have happened instead?
- What do I do about it?
A consolidated view answers the first. The other three still land on a person.
The data cannot tell you what should have happened
To know something is wrong, you need a reference for what right looks like. That usually does not live in the transaction records. It lives in the institution's contracts, fee schedules, network rules and policies.
Put two numbers side by side and the data can show you they differ. It cannot tell you which one the agreement supports, why the gap exists or what should happen next.
Cordant starts where the consolidated view stops
Cordant takes what the institution's agreements say should happen and compares it with what the systems say did happen. When the two diverge, Cordant puts the cause, the evidence and the proposed next step beside the exception.
The person who owns it still decides what happens. But they no longer start from a difference and work backward to find out what it means.
Ask what changes on Monday
Before the next consolidation project gets signed off, ask one question: what will the person opening this on Monday morning do differently?
If the answer is "look at it," the project moved the data. It did not move the work.




