ISO 20022 without rewriting the core banking system

Two gaps where the problem lives

The move to ISO 20022 creates two difficulties for the bank — and they sit in different places.

The Three Registers: Strict Isolation of Purpose, Tax IDs (TXID), and Clean Remittance

Naïve converters dump tax numbers, budget codes, and free-text descriptions into a single unstructured field, causing correspondent filters to halt or reject the payment. ODG-PASS enforces strict Three Registers isolation:

Connection Parameters Matrix: Global SWIFT CBPR+ vs. Georgia & SEPA Contour

Detailed technical specification of listening ports, protocols, message schemas, and integration points for On-Premise bank deployment:

This bank’s contour — customer intake to SWIFT

The gateway operates inside this bank. It receives customer instructions, structures them into pain.001.001.09, and presents verification findings to the operations desk. Once the officer confirms structure, this bank emits clean pacs.008 and cover pacs.009 COV directly to SWIFT on the channels the bank already has. The core accounting system is not rewritten.

Together. The sender closes what they can see before send. Operations closes what the sender cannot. Clean pacs.008 on the wire. Format translation in the bank contour — not two products competing on SWIFT.

Where the gateway sits

The gateway is installed in the bank’s contour, on the bank’s equipment, on top of the core banking system.

The core is not rewritten. The gateway is a layer between intake channels and the outbound flow to the network: unpack, check, assemble.

Data does not leave the bank’s contour. Processing is local. Interaction with the network uses the channels the bank already has connected.

What the gateway does with inbound flow

• Takes what is already there. Bank clients are not asked to change systems or install anything. Instructions arrive from the channels the bank runs today (standard pain.001, legacy free-text requisites, or accounting file dumps).
• Structures customer intake into standard pain.001.001.09. Street, building, post code, town, and country are verified as structured pairs. The trna enzyme reads the purpose narrative and verifies compatibility with the company's registered CIF business profile. Nothing is guessed or discarded.
• Checks completeness and correctness. Mandatory fields, identifier formats, account check digit, bank code against the directory, CBPR+ usage rules.
• Queues the payment by state. Hold, operations review, ready to release. Operations sees the flow as a whole: what needs a person, what can move.

What the gateway does with outbound flow

Emits pacs.008 and cover pacs.009 COV in full. Every verified and structured element is packaged with network AppHdr and UETR for direct transmission to SWIFT Alliance. Nothing is dropped.

Prepares MT for correspondents that have not moved — and shows the losses

When structured data is folded into MT, part of it does not fit. That usually happens in silence: the message leaves, the data disappears, and the bank learns from a correspondent query or a return.

The gateway shows the loss list before send: what did not fit, from which field, by how much. Operations sees it and decides — send as is, fix, or ask for clarification. The list is written to the decision trail. A month later it is possible to see what left truncated and who accepted that.

Purpose codes

The sender describes the purpose in their own words. The network requires a code. The correspondent requires a code. Matching description to code is done by hand, and differently by different people.

The gateway reads the description, proposes a code from the ISO 20022 classification, and shows the grounds — why this one. Operations confirms or picks another. Both the original words and the structured code stay in the message. One does not replace the other.

Operations desk

A finding comes with grounds, not only as an error

• Which rule fired — with a code that can be named in correspondence
• On what grounds — a reference to a standard requirement, a usage rule, or a bank policy
• What to fix — original value and proposed value, side by side
• Which message field it belongs to

Operations does not parse XML line by line. The screen shows what needs a decision, and why. Applying a proposal is a human action: Accept structure proposal.

The original message stays unchanged

The inbound message is frozen and stored as received. Work is done on a working copy. The difference is an explicit list of changes — not a visual compare.

A person decides

For each finding, operations chooses: accept the proposal, correct it, request documents from the sender, or reject. While blocking findings are open, release is not possible — a system limit, not staff discipline.

Flow tape

Transactions sit on a tape with state marks: waiting, in review, ready to release, approaching cut-off.

Decision trail and operations journal

For each payment a full history is kept:

• What changed — the field, old value, new value
• Who changed it — operations or the system
• On what grounds — rule code and its source
• When — with a precise timestamp
• Which rule-pack version was in force at the check

That gives the bank three things. An answer to a correspondent query a month later — assembled from the trail, not from memory. Material for internal control and audit — every decision dated and grounded. A way to reconstruct an incident — not only what happened, but why that decision was taken under the rules then in force.

Assistant for unstructured data

A local assistant is built into the gateway for one job: unpacking unstructured data — mainly addresses, where no formal rule exists.

• Runs inside the contour. The model sits on the bank’s equipment. Data is not sent out.
• Proposes, does not decide. The parse becomes a proposal. The finding is formed by a rule, with a source — not by the assistant. A person decides.
• The bank switches it on or off. If policy does not allow this tool on the payment flow, it is switched off and the gateway continues without it. The switch position is recorded with the decision on each payment.
• Every call is logged. Input, model version, output. An address parse is a judgement; it can be reproduced later only from the record.

Rules by jurisdiction

Payment requirements differ by country and change over time. Standard releases come yearly; regulators issue amendments; effective dates move.

The gateway core does not contain the rules of a particular jurisdiction. Rules arrive as packs: each pack has a version, an effective date, a source, and an owner. When a requirement changes, the pack is updated — not the program. The bank sees which pack version applied to each payment.

Install and pilot

• Deploy in the bank’s contour. The gateway is installed on the bank’s equipment. Network traffic uses the channels the bank already has connected.
• Pilot on a copy of the flow. The first step runs on a copy of live traffic. Real messages, real findings, no effect on payments. The bank sees what the gateway finds in its own flow before anything is decided.
• Security-service review. Timing and order follow the bank’s own procedure. Local processing simplifies that review.
• Training. The workplace is built for a back-office employee, not a developer. Materials and rule descriptions ship with the system.

Scope of the solution

What the bank gets

The move to the new standard stops being a choice between rewriting every system at once and working with losses.

Inbound flow from older channels is unpacked and completed. Outbound is formed in full. Where it cannot be made full, the bank knows that before send — not after a return. Every decision is recorded and grounded. Rules update without a program change. The core banking system stays untouched.