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.
Architecture
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
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 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
Treasury Bank Connectivity: SWIFT vs Host-to-Host vs API vs 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.
ISO 20022 Payments Explained: pain.001, pain.002 and the camt Family
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.
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.
Integration
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
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 Systems
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.
Follow the build → — one practical finance-systems pattern, product decision or build lesson every two weeks.