Topic
Treasury Systems Architecture & Connectivity
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.
A Reference Architecture for Corporate Treasury
How the pieces of a corporate treasury landscape fit together: ERP, TMS, bank connectivity and market data, connected by defined interfaces — with a system-of-record matrix for who owns which data.
What Is the Treasury System of Record?
A system of record is the single authoritative source for a set of data. Designating one for treasury — and drawing a clean boundary between the TMS and the ERP — is what prevents the 'two numbers, which is right?' problem. How to define it well.
The Treasury Data Model
The treasury data model is the structure of the data a treasury system holds — the core entities (deals, positions, cash flows, exposures) and the reference data (counterparties, accounts, instruments) they depend on. Why every report, valuation and control rests on it.
Treasury Bank Connectivity: SWIFT vs Host-to-Host vs API vs EBICS
The main ways corporate treasury connects to banks — SWIFT, host-to-host, API and EBICS — compared on reach, cost, real-time capability and effort, with how to choose for your bank landscape.
Bank Statement Formats: MT940 vs camt.053 vs BAI2
MT940, camt.053 and BAI2 are the main bank statement formats treasury systems import. MT940 is the legacy SWIFT flat file, camt.053 the modern ISO 20022 XML, BAI2 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 corporate payments, pain.001 is the payment instruction you send and pain.002 is the status report back — with camt for statements. What they are and why the migration matters.
Designing ERP-to-TMS Integration
How to design the integration between your ERP and treasury system: what flows each way, batch vs real-time, reconciliation and ownership — so the two systems stay in step instead of drifting apart.
Interface Monitoring and Reconciliation for Treasury Systems
Treasury interfaces fail silently and partially — producing wrong positions and missed payments. Interface 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, security prices — is the external reference data treasury needs to value positions and revalue exposures. How to source it, control the official rate, and integrate it without corrupting your valuations.
Straight-Through Processing in Treasury
Straight-through processing (STP) means a transaction flows from initiation to settlement and accounting with no manual re-keying. Why every manual touchpoint is a place for error and fraud, what breaks STP, and how to raise your STP rate.
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. How SoD, four-eyes approval, access control and audit trails combine into treasury security.
Follow the build → — one practical finance-systems pattern every two weeks.