Every KSA bank that connects to SAMA IPS is already running ISO 20022. The pacs.008 credit transfer message is live. The reject path — the pacs.002 status report arriving asynchronously from IPS — is live. In most banks, the team that built that integration has moved on, the documentation is incomplete, and the coexistence problem — handling inbound MT103 from SWIFT correspondents who have not yet migrated — has been deferred to “later.” Later is 2027.

ISO 20022 is not primarily an integration project. The translation layer is the tractable part: a mapping from SWIFT MT fields to ISO 20022 XML elements, enriched with IBANs from the core account master and a purpose code from a lookup table. Engineers can build that in weeks. The hard part — the part that stalls at a VP’s desk — is everything that sits around the translation: who owns the purpose code table when SAMA updates it, what the coexistence strategy is for the two-year period before SWIFT retires MT, and what it means when the first batch of SWIFT rejects arrives and the team discovers the reject-handling path was never tested.

What SAMA actually audits

SAMA’s IPS Technical Specifications are publicly available to participants. What is less obvious is what the SAMA examiner actually looks for during a payments infrastructure review. The answer is not the architecture diagram. It is the operational evidence: the test logs from the SAMA sandbox, the reject-handling procedure, the purpose code governance process, and the monitoring dashboard that shows pacs.002 consumption latency.

A bank that has built a technically correct translation layer and can demonstrate a tested reject path, a maintained purpose code table, and a monitoring setup that surfaces IPS connectivity failures within sixty seconds is in a better position with SAMA than a bank that has an elegant architecture with no operational evidence behind it. The examiner’s question is not “explain your mapping logic.” It is: “Show me the last test you ran against the SAMA sandbox and what you found.”

Purpose code governance is the most commonly underestimated operational discipline in ISO 20022 programmes. SAMA updates the IPS purpose code list. If nobody owns the update process, the first time a deprecated code is submitted, the payment fails at the IPS gateway with a reason code that the support team does not immediately recognise. That is a SAMA finding, not just a support ticket.

The coexistence decision leadership has to make

The SWIFT CBPR+ coexistence window — the period during which both MT103 and pacs.008 are accepted for cross-border payments through SWIFT — runs from 2025 through November 2027. During that window, a KSA bank will receive inbound payments from correspondents in one of three states: already migrated (sending pacs.008), in coexistence (sending either), or unmigrated (still sending MT103). The receiving bank must handle all three.

The leadership decision is whether to build the MT coexistence path now or to defer it until the volume of inbound MT traffic forces the issue. This is not a technology decision — the translation layer can be extended to handle inbound MT103 in parallel with inbound pacs.008, and the engineering complexity is well-understood. It is a resourcing and risk decision: how much incoming payment volume is currently arriving as MT103 from unmigrated correspondents, and what is the business impact of rejecting those payments with a “format not supported” status?

For most KSA banks with a mix of GCC and international correspondents, the practical answer is that a non-trivial fraction of inbound cross-border volume will remain in MT103 format through 2026 and into 2027. Deferring the coexistence path means either accepting those payments through a manual workaround or rejecting them, both of which are worse outcomes than the engineering work required to handle them properly.

The decision the architecture team needs from leadership

Three decisions that cannot be delegated below VP level in a regulated bank:

What is the coexistence posture? Does the bank accept inbound MT103 during the CBPR+ window and translate to canonical form, or does it reject MT103 and require correspondents to send pacs.008? The second option is simpler to build but requires communicating a migration deadline to all correspondent banks — a relationship management exercise, not a technical one.

Who owns the purpose code table? The ISO 20022 purpose code is a mandatory element in SAMA IPS submissions. SAMA publishes an approved code list and updates it. Someone has to own the process of monitoring SAMA circulars, updating the lookup table in the integration layer, testing the new codes against the sandbox, and releasing the update before the old codes become invalid. This is a permanent operational function, not a one-time configuration task.

What is the testing mandate? The SAMA sandbox exists for a reason: testing ISO 20022 submissions end-to-end, including the asynchronous reject path. The question leadership has to answer is how frequently the integration team must run end-to-end sandbox tests, what the success criteria are, and who signs off the results. Without a mandated testing cadence, the sandbox testing that happened during go-live does not repeat, and the integration drifts from the SAMA specification as purpose codes are added and schema versions change.

What the team needs from leadership to ship it

The ISO 20022 integration is one of the few integration projects where the operational burden does not diminish after go-live. Most integrations, once stabilised, require only incident response. ISO 20022 requires ongoing attention: SAMA spec updates, purpose code table maintenance, CBPR+ coexistence handling, and the schema version migration that the November 2027 SWIFT deadline will require.

The ask from the integration team is not additional budget — the translation layer, once built, is not expensive to run. The ask is a clear ownership model: who monitors for SAMA specification changes, who owns the purpose code governance process, who signs off sandbox test results, and who has the authority to release an updated purpose code table without going through a full change management cycle that takes longer than SAMA’s publication lead time.

The teams that have handled this well at KSA banks have made two structural choices: they have designated a payments operations function (distinct from the integration engineering team) that owns the SAMA relationship and monitors specification changes, and they have built a lightweight, database-backed purpose code lookup that can be updated by the operations function without an engineering release cycle. Neither of these is architecturally complex. Both require a leadership decision to establish them before go-live, not after the first SAMA reject.

For the engineering depth behind this topic — MT-to-MX field mapping rules, IBAN enrichment in IBM ACE, Camel K route configuration for ISO 20022 transformation, SAMA IPS mandatory extensions, and the testing matrix for pacs.008 rejects — see the companion Lab article: ISO 20022 Transformation Patterns: MT-to-MX Migration in Production.