In MDB Treasury transformations, the Target Operating Model (TOM) is the blueprint for processes, control objectives, data lineage, and governance. It only creates value if it survives build and cutover, and is evidenced in configuration, operating controls, and audit artefacts.
1. The TOM is proven in delivery, not design
Once vendors start configuring, decisions tilt toward scope, timelines, and tool constraints. Without strong governance, vendor defaults (workflow, static data model, control points) start redefining the operating model.
2. Oversight protects intent without slowing delivery
Oversight is design-to-config traceability: maintaining a live chain from capability and control intent → requirements → configuration → test scripts → evidence. Practically, it protects: booking models and product/CSA setup; limits and pre-/post-trade controls; maker-checker and SoD; valuation/exposure ownership; and STP across FO/MO/BO through to settlement and GL posting, with explicit exception queues and override controls.
3. The real failure mode is implementation drift
Drift looks like “reasonable” shortcuts: manual reconciliations replacing automated controls, de-scoped exposure/margin forecasting, deferred reports, interfaces with weak validation, or workarounds that bypass approvals. Individually tolerable, collectively they erode assurance, timeliness, and liquidity visibility.
4. Why is this amplified in MDB environments
Implementation choices become the control environment: golden sources, reconciliation breaks and tolerances, data lineage from trade → risk → settlement → GL, and auditable evidence for policy and stakeholder transparency. This is not just workflow; it’s the build of defensible governance.
5. What good oversight keeps “always on”
- Is TOM→requirement→config→test→evidence traceability intact?
- Are key controls implemented (limits, eligibility, approvals, reconciliations, overrides)?
- Are trade-offs explicit, documented, and governance-approved, vs vendor convenience?
Prodktr’s Perspective
“A TOM shouldn’t end as a document. It should survive as configured workflows, controlled data, and defensible evidence, especially under stress.”
Contact us for more information.