Treasury Technology and Systems
What the domain tests
Treasury technology and systems tests the treasury management system, bank connectivity, payment workflows, data standards, controls, and implementation. The exam expects you to know how cash data and payments move end to end and how straight-through processing and reconciliation are measured.
Core rules and concepts
- TMS scope. A treasury management system supports cash positioning, forecasting, payments, bank reconciliation, debt and investment management, FX, and reporting. It usually integrates with ERP and banking systems.
- Connectivity. SWIFT, host-to-host links, APIs, and bank portals differ in cost, speed, and data richness. SWIFT MT messages are being replaced by ISO 20022; CAMT.053 is a bank statement, PAIN.001 is a payment initiation, and PACS.008 is a customer credit transfer.
- Controls. Role-based access, segregation of duties, dual approval, audit trails, encryption, single sign-on, and penetration testing protect payment integrity.
- STP and reconciliation. Straight-through processing measures payments that complete without manual intervention. Reconciliation rules match bank statement lines to ledger entries; exceptions need defined ownership.
- Implementation. Requirements, data mapping, testing, cutover, and business continuity planning determine whether go-live succeeds.
Worked example
A company processes 10,000 payments a month. 9,400 pass automatically, so STP is 94%. If an automated payment costs $1 and a manual exception costs $12, monthly cost = 9,400 × $1 + 600 × $12 = $9,400 + $7,200 = $16,600. If STP rises to 97%, cost = 9,700 × $1 + 300 × $12 = $9,700 + $3,600 = $13,300, a saving of $3,300 a month. The business case depends on exception cost and volume, not only on the STP percentage.
Traps that cost marks
Treating MT and ISO 20022 as interchangeable; assuming API connectivity eliminates reconciliation; ignoring bank fees; weak user-access controls; going live without a continuity plan; and underestimating data-mapping effort.