A Reference Architecture for Corporate Treasury

A corporate treasury reference architecture has four layers — source systems (the ERP), the treasury system (a TMS or ERP treasury module), bank connectivity, and market data — connected by defined interfaces, with a clear system of record for each type of data. Most of the value, and most of the risk, lives in the connections and the ownership decisions, not in the individual systems. Get the interfaces and the system-of-record boundaries right and the landscape stays clean; get them wrong and you buy years of reconciliation.

The reference architecture

At a high level, it looks like this:

                    ┌──────────────────┐
                    │   Market data    │  FX rates, interest rates
                    └────────┬─────────┘
                             │
   ┌───────────┐      ┌──────┴───────┐      ┌───────────────┐
   │    ERP    │◄────►│  Treasury    │◄────►│     Banks     │
   │ GL·AP·AR  │      │  system (TMS)│      │ statements in │
   │ master    │      │ cash·risk·   │      │ payments out  │
   │ data      │      │ payments     │      │               │
   └───────────┘      └──────────────┘      └───────────────┘
        source            core treasury          connectivity

Four layers, each with a clear job, joined by governed interfaces:

The four layers

• Source systems (ERP). The accounting and operational backbone — the general ledger, accounts payable and receivable, and much of the master data. It is the source of truth for what happened financially.
• Treasury system (TMS or ERP treasury). The core treasury engine: cash positioning and forecasting, payments, financial-risk management, debt and investments. It consumes data from the ERP and produces accounting back to it.
• Bank connectivity. The channel to the outside world: statements come in (MT940, camt.053, BAI2) and payments go out (pain.001 / ISO 20022) over SWIFT, host-to-host, API or EBICS. Often a bank connector or integration layer sits here.
• Market data. FX and interest rates feeding valuation, risk and forecasting.

System of record: who owns what

The single most consequential architectural decision is assigning a system of record to each data domain — one owner, everywhere else a copy. Here's a defensible default; adapt it to your landscape, but decide it explicitly.

The interfaces

Design the connections deliberately, not as a web of point-to-point extracts:

• ERP → TMS: AP/AR and reference data for forecasting and payments.
• TMS → ERP: accounting entries to the GL (and sometimes payment status).
• TMS ↔ Banks: statements in, payments out, acknowledgements back — usually the critical path in any implementation.
• Market data → TMS: rates for valuation and forecasting.

Each interface should follow the system-of-record decisions — a field flows from its owner — and be monitored and reconciled, so a broken feed is caught before it becomes a wrong number.

An interface register makes the direction and the ownership explicit — and names what a silent failure of each one actually costs:

Keep this register next to the system-of-record table: one says who owns each field, the other says which pipe carries it and what breaks if it's quiet.

Environments

Finance systems need a proper environment strategy — typically development, test, and a pre-production environment that genuinely mirrors production, then production. The pre-prod discipline matters: in one landscape, pre-production was quietly treated as "another test environment," and teams changed static data in Test and Pre-Prod independently — which produced configuration drift that only surfaced at go-live. Keep environments controlled and their data governed.

What usually goes wrong

• No system-of-record decision. Two systems own the same data; reconciliation becomes a permanent job.
• Point-to-point spaghetti. Interfaces built ad hoc as extracts, undocumented and unmonitored, until no one can safely change anything.
• Dirty master data. Bank accounts, counterparties and mappings maintained inconsistently across systems.
• Unmonitored interfaces. A feed fails silently and the first sign is a wrong position or a missed payment.

Design principles

Keep four principles in view: one owner per data domain; interface-based, governed integration rather than point-to-point; master data owned and clean; and every interface monitored and reconciled. Follow them and the architecture is a stable foundation. Skip them and each new system makes the landscape harder, not easier.

Start with ownership: the free Treasury System-of-Record Map applies the first principle — one owner per data domain — flags anything that breaks it, and exports a table you can drop straight into your architecture doc.

Part of the Treasury Systems Architecture guide. See also what a TMS is and bank connectivity options. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.