For multilateral development banks (MDBs), treasury spans borrowing programmes, investments, derivatives, currency exposures and concessional structures, across several systems and teams. A single transaction may be relied on by front office, operations, risk, finance and reporting within hours.
Modernisation usually starts with the platform question: which system, which vendor. That matters, but it rarely decides whether reporting can be trusted afterwards. Data ownership, controls, integration and reporting logic should be designed alongside processes and roles – not retrofitted once a platform is live.
1. One trade, many uses
Suppose a transaction is booked with an imprecise product classification. It settles cleanly, because the cash and counterparty details were right. The error only surfaces later – in the accounting and a board report – after several processes have already used the record. Fixing it means unwinding postings, restating a report and explaining a variance that showed no symptom when it arose.
The same happens when reference data differs between two systems, a missing market input lets a valuation default silently, or a trade is captured twice – once in a system, once in a spreadsheet. The weakness is architectural, not individual. No obvious mistake was made; the design let one weak point spread.
2. Data architecture is part of the operating model
A treasury operating model sets out who does what, in what order, under what controls. Data architecture sets out what is recorded at each step, where it sits, who owns it and how it moves. They describe the same operation. Built separately, they disagree – and the disagreement shows up in implementation as manual workarounds.
Designing them together means answering a few questions early:
- Which system is the single source for each data domain?
- How does a transaction flow from initiation to reporting, and where does responsibility change hands?
- Who owns each domain in business terms, not who runs the system?
- Are controls early enough to prevent downstream correction?
- Can accounting and reporting outputs be traced back to the transaction record?
None are technology questions first – they are operating model questions with technology consequences.
3. Architecture has to work in practice
A design that reads well on paper is not yet proof. Across recent MDB platform evaluations, selection and proof-of-concept exercises are where data architecture is validated – or quietly assumed.
Vendor demonstrations are built around functionality. A requirement is listed, the system shows a screen that meets it, and the box is ticked. That proves the feature exists – not that data stays accurate and traceable as it crosses capture, valuation, accounting and reporting.
More useful tests run real transactions end to end and watch what happens:
- whether records stay complete and consistent across the lifecycle;
- how reference and market data enter, and what happens when a feed is late or incomplete;
- whether accounting and ledger entries reconcile to source without manual adjustment;
- how exceptions, amendments and overrides are raised, routed, evidenced and closed;
- how much manual intervention it actually needs.
The last point is often the most revealing. Judge a platform not on whether a feature appears in the spec, but on whether data stays accurate, controlled and traceable across a full process – and on the evidence it leaves behind.
4. What effective treasury data looks like
Treasury data that holds up under scrutiny shares a few traits.
- Ownership is named. Each domain has a business owner accountable for its definitions and quality, separate from the team that runs the system.
- Data is captured once, at the point where it is best known, and reused rather than re-entered.
- There is one agreed source per domain. Not one database for everything – but a documented hierarchy and controlled distribution wherever the same attribute lives in more than one system.
- Controls sit early. Checking at capture costs less than correcting at reporting, and saves the reconciliation otherwise needed to find the error.
- Exceptions are visible, owned and time-bound. A queue with no owner and no deadline is just a backlog.
- Outputs are traceable. Any figure in a report can be followed back to the transactions that produced it, without reconstruction.
Prodktr’s Perspective
Trusted reporting is not made at the reporting stage. It is made upstream, in how data is captured, owned, validated and reconciled. For MDBs modernising treasury, the steps are practical: agree who owns each domain before choosing a system; design data alongside process, roles and controls, not after; put validation as close to capture as possible; and make every figure traceable from source to report. Do this during operating model design and reconciliation is faster, reporting more reliable and implementation less risky. Defer it, and the same controls get rebuilt later – by hand, under pressure.
Contact us for more information.