Transaction Manager: the shared record of an ISO 20022 payment

Transaction Manager is the SWIFT platform that holds a shared, central record of an ISO 20022 cross-border payment, so that every bank in the chain can see the same transaction data, in the same format, even when the banks use different systems and different message versions. It is the answer to the problem that MT messages were point-to-point, so each bank saw only its own leg, and nobody had the whole picture. With Transaction Manager, the full pacs.008, with its rich data, is stored once, and each bank reads the data it needs from the shared record, which means the beneficiary details, the remittance information and the charges are not truncated or lost as the payment moves. Source: SWIFT Transaction Manager service description, and SWIFT CBPR+ usage guidelines. Why Transaction Manager exists is that ISO 20022 payments carry far more data than MT payments did, and that data is the value of the migration. A pacs.008 can carry structured remittance information, structured addresses, purpose codes and LEIs, but if each bank in the chain translates the message into its own internal format and back, the data is truncated, translated or lost, and the beneficiary receives a payment with less information than the debtor sent. Transaction Manager stops that by holding the complete transaction centrally, so the data survives the journey, and each bank can also perform in-flow translation, converting between MT and ISO 20022 as needed, without losing the underlying data. The platform exists to protect the data, not just to move it. The parties are the banks in the payment chain, which send their messages to Transaction Manager and read the shared record, and SWIFT, which operates the platform and holds the data. The debtor and the beneficiary are not direct users of the platform, but they are its beneficiaries, because the debtor remittance data reaches the beneficiary intact, and the beneficiary can reconcile automatically. Each bank must be able to send and receive the ISO 20022 messages that Transaction Manager expects, and must be able to correlate its own internal payment record with the shared transaction, usually by the UETR, which is the key that links the two. How it works is shown by a worked example. A bank in Paris sends a pacs.008 for EUR 320,000 to a bank in Singapore, with structured remittance listing four invoices, a purpose code and the LEI of the debtor. The Paris bank sends the message to Transaction Manager, which stores the full transaction and forwards the pacs.008. The intermediary bank, which still runs an MT-based system, receives an in-flow translation to MT103, but the full ISO 20022 data remains in Transaction Manager, so when the Singapore bank, which is ISO 20022 native, reads the transaction, it receives the full pacs.008. Without Transaction Manager, the intermediary translation would have truncated the remittance to 140 characters and the beneficiary would have reconciled only one invoice. On success the data arrives intact, the beneficiary reconciles automatically, and the banks can track the transaction in one place, which reduces investigations. On failure the shared record can be out of sync with a bank internal record, for example if a bank updates its own system but does not update Transaction Manager, and then the two records disagree about the status, and the investigation must decide which one is right. The recovery is a reconciliation between the bank internal record and the shared record, using the UETR, and a process that prevents the two from diverging, because a shared record that is not trusted is worse than no shared record at all. The data in Transaction Manager is the full ISO 20022 transaction, including the group header, the payment information, the credit transfer transaction, the remittance information, the charges and the status history. The status history is as important as the payment data, because it records every state change, from receipt to acceptance to settlement to credit, with timestamps, so any bank in the chain can see where the payment is without asking. A BA must specify which data the bank reads from Transaction Manager, which data it writes, how it correlates the shared record with its internal record, and what happens when the two disagree, because those are the integration points where the implementation fails. Edge cases show the limits. A payment that is sent outside Transaction Manager, because one bank in the chain does not participate, will not have a shared record, and the data will be carried only by the messages, so the bank must know which of its corridors are covered and which are not. A payment that is modified after it is sent, for example by a camt.087 value-date change, must update the shared record, or the next bank will act on stale data. A payment that is recalled with camt.056 must update the shared record to show the recall, or a bank that reads the record later will think the payment is still in flight. The effect on the bank is richer data for its customers, fewer truncation losses, and a single place to look when a payment is investigated. The effect on the customer is automatic reconciliation, because the remittance data arrives intact, and fewer manual exceptions. The effect on operations is a new system to monitor, with a reconciliation between the internal record and the shared record, and a queue for mismatches that must be worked daily, because a mismatch that sits for a week is a payment whose status cannot be trusted. What a BA, PO or SME must understand is that Transaction Manager is a data platform, not a payment rail, and its value is the data it preserves, not the speed it adds. The requirement must name the corridors covered, the data read and written, the UETR correlation, the in-flow translation rules and the reconciliation with the internal record. The test is to send one payment with structured remittance through a chain that includes an MT-based intermediary, and to check that the beneficiary still receives the full remittance, because if the data is truncated, the platform is not doing its job. Further reading: SWIFT Transaction Manager service description; SWIFT CBPR+ usage guidelines; ISO 20022 pacs.008 definition. Last reviewed 7 November 2026.