Topic
Treasury Systems Architecture: ERP, TMS & Banks
The plumbing of corporate treasury: how the ERP, the TMS, the banks and market data connect, which system owns which data, and how statements and payments actually move — SWIFT vs host-to-host vs API, MT940 vs camt.053, ISO 20022.
This is where most of the value and most of the risk of a treasury landscape lives — in the connections, not the boxes. Written from real integration and transformation work.
32 articles · ~198 min, in 4 sections — each in reading order
Architecture
7 articles · ~37 minA Reference Architecture for Corporate Treasury
How a corporate treasury landscape fits together: ERP, TMS, bank connectivity and market data, joined by defined interfaces, with a system-of-record matrix.
What Is the Treasury System of Record?
A treasury system of record is the single authoritative source for its data. Designating one, and the TMS-vs-ERP boundary, ends 'which number is right?'
The Treasury Data Model
The treasury data model is the structure of a treasury system's data — the core entities and the reference data they depend on. Why every output rests on it.
Treasury Master Data Management
Treasury master data is the static reference data everything depends on — banks, counterparties, instruments, settlement instructions — and ownership is key.
Treasury Data Quality and Governance
Treasury data quality decides which numbers you can trust — cash, exposure, valuation, forecast are all computed from it, and governance keeps it clean.
Treasury Data Lineage: Source to Reported Number
Answer 'where did this number come from?' in minutes, not days: trace any treasury figure from source transaction to reported number — and who owns each hop.
Treasury Reporting and Analytics Architecture
Treasury reporting architecture explained — operational, warehouse and BI layers — and why every reported number is only as trustworthy as its source.
Connectivity
15 articles · ~112 minTreasury Bank Connectivity: SWIFT, Host-to-Host, API, EBICS
SWIFT, host-to-host, API and EBICS — how corporate treasury connects to banks, compared on reach, cost, real-time capability and setup effort.
EBICS Explained: European Bank Connectivity
What EBICS is — an internet-based European standard for exchanging payment and statement files with banks — and where it fits alongside SWIFT and host-to-host.
Bank Statement Formats: MT940 vs camt.053 vs BAI2
MT940, camt.053 and BAI2 are the main bank statement formats treasury imports: legacy SWIFT, modern ISO 20022, a US format. How they differ and which to use.
camt.053 Structure: Reading the Statement Field by Field
The camt.053 statement field by field: GroupHeader to TransactionDetails, OPBD/CLBD balance codes, the Bank Transaction Code, and where bank files diverge.
camt.054: The Debit/Credit Notification and When You Need It
What camt.054 is — a notification of debits and credits, not a statement — how it differs from camt.053 and camt.052, and the lump-sum breakdown it exists for.
MT940 Format: The Tags, Line by Line
Every MT940 tag explained: :20:, :25:, :28C:, the :61: statement line subfield by subfield, the bank-specific :86:, and the :62a:/:64:/:65: balances.
BAI2 File Format: Records, Type Codes and How to Read One
Every BAI2 record explained: the 01–99 hierarchy, balance codes 010/015/040/045, credit vs debit type-code ranges, the funds-type field and control totals.
MT101 vs MT103 vs MT202: Which SWIFT Message Does What
MT101 is a corporate's payment instruction, MT103 a bank-to-bank customer transfer, MT202 an interbank transfer. How they differ and what replaced them.
ISO 20022 Payments Explained: pain.001 and pain.002
ISO 20022 is the global XML standard for financial messaging. For payments, pain.001 is the instruction you send and pain.002 the status back. What they are.
pain.001 Structure: The Fields That Actually Matter
Inside the pain.001 file: GroupHeader, PaymentInformation and the transaction level — which fields treasury maps, and where bank implementations differ.
pain.002 Status and Reject Codes: Reading the Bank's Reply
How to read a pain.002 status report: group, payment and transaction level, the ACTC/ACCP/ACSC status codes, and reject reasons like AC01, AC04 and AM04.
ISO 20022 Migration: Moving from SWIFT MT to MX (CBPR+)
The industry migration from legacy SWIFT MT messages to ISO 20022 MX for cross-border payments and reporting, and what CBPR+ means for corporate treasury.
SWIFT gpi: Tracking Cross-Border Payments
SWIFT gpi makes cross-border payments faster and trackable end to end, giving each a unique reference (UETR) so you can follow its status. What treasury gets.
Real-Time Treasury: What It Actually Means
Real-time treasury is the shift from batch to continuous operations, driven by instant payments and APIs. What changes, and where it genuinely matters vs batch.
Bank Connectivity Security: Keys, Certificates and Controls
The security layer under treasury bank connectivity: certificate and key lifecycle, mTLS, OAuth, key rotation, HSM, SWIFT CSP, and who owns the technical user.
Integration
5 articles · ~22 minDesigning ERP-to-TMS Integration
ERP TMS integration design: what flows each way, batch vs real-time, reconciliation and ownership — so your ERP and treasury system stay in step.
Treasury Integration Patterns: Files, APIs and Middleware
Treasury integration patterns — batch files, APIs and middleware — and their trade-offs, plus why point-to-point connections collapse under their own weight.
Interface Monitoring and Reconciliation for Treasury Systems
Treasury interfaces fail silently and partially. Monitoring proves each ran; reconciliation proves the data arrived intact. How to design both from the start.
Market Data in Treasury Systems
Market data (FX rates, interest curves, prices) is the external reference data treasury needs to value positions. How to source, control and integrate it.
Straight-Through Processing in Treasury
Straight-through processing (STP) means a transaction flows from initiation to settlement with no manual re-keying. Why every manual touchpoint is a risk.
Controls
5 articles · ~27 minSegregation of Duties in Treasury Systems
Treasury moves money, so it's a prime fraud target. Segregation of duties means no one person can initiate, approve and release a payment or trade alone.
Payment Fraud Prevention and Controls in Treasury
Payment fraud prevention in treasury: the main threats are BEC, invoice redirection, insider diversion and standing-data tampering — and how to stop them.
Access Management and User Provisioning in Treasury Systems
A treasury system can move money, so who can do what inside it is a first-order control. Access management is the foundation segregation of duties stands on.
Audit Trails and Logging in Treasury Systems
A treasury audit trail must capture who did what, when, and to what — the tamper-evident record that proves segregation of duties and approvals actually worked.
Disaster Recovery and Business Continuity for Treasury
Keeping treasury running through an outage: how RTO and RPO drive the design, and why the manual fallback is the plan that actually saves the payment.
Free tools for this topic
Frequently asked questions
What does a corporate treasury systems architecture look like?
At its simplest, four layers connected by defined interfaces: source systems (the ERP, holding the ledger, AP and AR), the treasury system (a TMS or the ERP's treasury module, handling cash, risk and payments), bank connectivity (the channel to banks for statements and payments), and market data (FX and interest rates). The value and the risk are in the interfaces and in deciding which system is the source of record for each type of data.
Full article →What is a system of record in treasury?
A system of record is the single, authoritative source for a given set of data — the system whose version is treated as definitive when systems disagree. In treasury, it's the system that holds the master version of deals, cash positions, exposures and bank data, typically the treasury management system. Designating one system of record per data domain is what lets an organization answer 'which number is right?' with certainty instead of a debate.
Full article →What is the difference between SWIFT, host-to-host and API bank connectivity?
SWIFT is a shared network that reaches many banks through one standardized connection — good for multi-bank reach, higher in cost and complexity. Host-to-host is a direct, secure file exchange between your systems and one specific bank — efficient for a few high-volume relationships. API connectivity is real-time and modern, bank-by-bank, best where you need instant balances or payment status. EBICS is a standard used mainly in parts of Europe. Most corporates use a mix, chosen by bank and need.
Full article →What secures a treasury bank connection?
Layered controls, not one setting. Transport is secured with TLS — often mutual TLS (mTLS), where both the client and the bank present certificates — so each end proves who it is and the channel is encrypted. Messages are additionally signed (proving origin and integrity) and often encrypted (protecting content), so a payment file is trustworthy even independent of the pipe it travelled through. Access is authorised: client certificates, EBICS keys, or OAuth client credentials for APIs. And all of it rests on identity and key management — whose keys, stored where, rotated when — plus monitoring so an expiry or anomaly is caught before it stops payments.
Full article →What is the difference between a system of record and a system of engagement?
A system of record holds the authoritative, master version of data — it's where the truth lives. A system of engagement or reference is a system that consumes and presents that data for a particular use, without owning it. A dashboard or a reporting layer can be a system of engagement built on top of the treasury system of record. The distinction matters because only the system of record's copy is authoritative; everything else is a view.
Full article →Follow the build → — one practical finance-systems pattern, product decision or build lesson every two weeks.