Topic
Treasury Systems Architecture: ERP, TMS & Banks
Treasury systems architecture is how the ERP, the TMS, the banks and market data connect: which system owns which data, how statements and payments actually move — SWIFT vs host-to-host vs API vs EBICS, MT940 vs camt.053, ISO 20022 — and the controls wrapped around it. This is where most of the value and most of the risk of a treasury landscape lives — in the connections, not the boxes.
The hub reads in four parts: the reference architecture and system of record first, then bank connectivity and the message formats field by field, then ERP–TMS integration patterns and monitoring, then the controls — segregation of duties, fraud prevention, access, audit trails, recovery. Start with the reference architecture. Written from real integration and transformation work.
43 articles · ~344 min, in 4 sections — each in reading order
Architecture
7 articles · ~37 minThe reference architecture and system of record first, then the data model, master data, data quality and governance, lineage, and reporting and analytics.
A 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: Core Entities and Reference Data
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
26 articles · ~257 minThe channels first (SWIFT, host-to-host, API, EBICS), then formats — MT940, camt.053/054/052, BAI2, MT10x, pain.001/008/002, NACHA — and ISO 20022 migration.
Treasury Bank Connectivity: SWIFT, Host-to-Host, API, EBICS
SWIFT, host-to-host, API and EBICS — how corporate treasury connects to banks. Host-to-host vs corporate SWIFT compared on reach, cost and who runs it.
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.
EBICS Order Types and BTF: INI, HIA, STA, C53, CCT
EBICS order types explained: INI, HIA and HPB for the keys, STA, C53, CCT and CDD for the files, and the BTF names that replace them in EBICS 3.0, by country.
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.
ISO 20022 and Swift Dates: What Changes When, 2025–2027
The ISO 20022 and Swift dates a treasury plans around: what ended in 2025, what was set for November 2026 and then deferred, and what moves to June 2027.
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.
ISO 20022 Bank Transaction Codes: The Full List
Bank transaction codes in camt.052, camt.053 and camt.054: how domain, family and sub-family work, and all 1,564 combinations ISO permits, each spelled out.
camt.054 Explained: Debit/Credit Notification vs camt.053
What a camt.054 message is: the ISO 20022 debit/credit notification. No balances, just the detail inside a booking — and how it differs from camt.053.
camt.052 vs MT942: The Intraday Report, Field by Field
camt.052 and MT942 side by side: what each intraday report carries, the balances camt.052 may omit, MT942's floor limit and totals, and where banks diverge.
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.
MT940 Transaction Type Codes: NTRF, NCHG, NDDT and the Rest
The MT940 :61: transaction type codes in full: what the S, N and F letter means, and all 57 three-letter codes from TRF and CHG to the securities set.
Value Date vs Booking Date vs Entry Date on a Bank Statement
Value date, booking date and entry date on a bank statement: what each means, where it sits in camt.053, MT940 and BAI2, and which date your cash position uses.
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 for Corporates: pain, camt and pacs Messages
The ISO 20022 messages a corporate treasury meets — pain.001, pain.002, pain.008, camt.052/053/054, camt.086 and pacs — and which guide covers each.
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.008: SEPA Direct Debit Initiation Explained
pain.008 (CustomerDirectDebitInitiation) is the ISO 20022 message a creditor sends to pull funds — mandates, FRST/RCUR sequence types, Core vs B2B, refunds.
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 Status Reason Codes: The Full List
Every ISO 20022 status reason code a pain.002 can carry, AB01 to WGDB: all 315 in the 2Q2026 external code set, each with ISO's own name and definition.
EndToEndId vs UETR: ISO 20022 Payment References
MsgId, PmtInfId, InstrId, EndToEndId, TxId and UETR compared: who assigns each payment reference, how far it travels, and which one returns on the statement.
Remittance Advice: What It Is and How It Travels
A remittance advice says what a payment is for. Where it travels — inside the payment, as ISO 20022 remt.001, X12 820 or a PDF — and how it gets matched.
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.
ACH Return Codes: NACHA File Format and R01–R85 List
Every NACHA ACH return code from R01 to R85 with its official title, and the file behind it: record types 1–9, key fields, SEC codes and return time frames.
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 minERP-to-TMS integration design, the patterns (files, APIs, middleware), interface monitoring and reconciliation, market data, and straight-through processing.
Designing 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 · ~28 minSegregation of duties, payment fraud controls, access management and provisioning, audit trails and logging, and disaster recovery and business continuity.
Segregation 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
Also from me: BankLint — Validate pain.001 payment files before your bank does — then compare each new file with the last one your bank accepted.
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 →Work with me → — the workflows this hub documents are exactly the kind I redesign with AI: slow, manual, exception-heavy, and still answerable to a control review.