ODG-PASS — bank gateway in the bank contour + client terminal. Structured data by keys when connected, or pain.001 as a file. The bank forms pacs.008. Public demo free · unlock for the working terminal · Windows client.
ODG-PASS · ISO 20022 · gateway + client terminal
The payment leaves for the network complete. Or it does not leave at all.
ODG-PASS forms correct structured payment data — from the client to the bank. Two doors: the client terminal (check the payment before you send it) and the bank gateway with the officer console in the bank contour. Choose your door below. Format translation for the bank is on the bank page.
Returned with no clear reason? Usually the message was not structured for the new standard. Fix the fields before they reach the bank — then confirm arrival.
Public demo · no keyWorking terminal after unlockWindows client · open download
Clean fields in. Clean pacs.008 out — through to the beneficiary. Same ISO 20022 / CBPR+ rules. Format translation MT ⇄ MX stays in the bank contour, at the sender and already at the receiver. Not a second SWIFT network. The check is the library and the rules — not a generative model.
client → beneficiary · structure on the wirelive · simulation
Client
dbtrACME TRADING
purp"goods"
addr: unstructured ⚠
Terminal · library + rules
✓Structure · fields
✓Purpose · ISO code
Sender bank
pacs.008
PurpGDDS
addrtown / country
MT ⇄ MX in contour
Network
clean pacs.008
Bank sends with its own means
Receiver bank
pacs.008 in → beneficiary
cdtrbeneficiary
MX ⇄ MT in contour
CLEAN pacs.008
1 fields2 structure check3 bank forms pacs.0084 on the wire5 receiver · MX⇄MT · beneficiary
Client
Before the payment goes to the bank
You fill the paymentAmount, parties, IBAN, BIC, town and country as fields, purpose as an ISO code, charges.
Terminal checks structureLibrary and rules. Which field. What to do. 🟢🟡🔴 is guidance — not a bank block.
You send to your bankBy keys if connected, or pain.001 as a file. This site does not keep the payment as a client file.
The bank posts the fundsThe bank’s server forms pacs.008. Debit / post stays at the bank.
Bank
Inside the bank contour, before release
Message enters this installFrom this bank’s client terminal, or MT / MX from the market.
Officer consoleAs received, frozen. Findings on the field. Working copy. Propose from the library; the officer writes.
This bank forms pacs.008If a correspondent still takes MT, losses are shown before send. Empty book → not_checked.
On the wire, then the receiverThis bank sends a clean pacs.008 with its own means. At the receiving bank the same suite can take MX in and, if that host still needs MT, translate MX ⇄ MT in that contour — already at the beneficiary’s bank. Not a second SWIFT network.
Together. The client closes what they can see before send. The officer closes what the client cannot. Clean pacs.008 on the wire to the beneficiary. MT ⇄ MX in the bank contour, both ends — not two products competing on SWIFT.
Honest scope
Structure check — not a bank compliance decision
ODG-PASS helps you see structure problems early and prepare fields — before they reach the bank. It does not replace your bank's compliance department.
Explains which field to fix — 🟢🟡🔴 with clear field guidance
Correspondent guidance — large amounts, cross-border, documents
Shows a demo sanctions signal for manual review — not a block
By bank agreement, acts as a transition channel when e-banking cannot yet carry the new format
Prepares the message for the bank to debit / post the funds
What it does not do
Full OFAC / UN / EU screening or bank AML/CFT
Execution and the account stay at the bank
Legal approval or guarantee the bank will accept the payment
KYC, PEP, beneficial-owner checks, or regulatory filings
Replace e-banking without your bank’s agreement
Yellow flags are advisory — prepare invoice or contract if asked. Red means fix structured data before sending. The bank always has the final say.
Built on official standards:ISO 20022SWIFT CBPR+UBL 2.1ISO 13616 · IBANISO 4217 · 3166Rospatent RU2026682321
Who are you?
Enter as client · for banks
One product, two doors. Each door has a full explanation — not a slogan. GCC tax is a related path, not the payment terminal.
Client
I send payments
The client terminal is the check before you send the payment to the bank. It is not only a purpose-code picker. You enter the payment as the chain will see it: amount and currency, parties, IBAN and BIC, town and country as fields, purpose as an ISO code (from the wording of the deal — not the word GOODS), charges, remittance. The terminal then tells you what in this structure may fail at the bank and further on the network: account format, missing town, purpose that is not a code, a field longer than the limit, BIC versus country. For each finding: which field and what to do. The traffic light 🟢🟡🔴 is guidance — not a bank block and not an AML verdict.
You correct the fields, run the check again, and only then pass the message. If a connection is configured, structured data goes to the bank’s server by keys. If there is no access, the terminal issues pain.001 as a file and you deliver it to the bank. The bank’s server forms pacs.008 and debits / posts the funds. The terminal prepares the message for that processing.
The payment is not kept as a client file on this public site. The check runs with you (browser or Windows client). Online-banking logins are not entered here. Until you send to the bank, the instruction stays with you. Open the demo, unlock the working terminal, or download the Windows client (installer open; access key issued separately).
The officer console is the operations desk inside this bank’s contour — after the message has entered the installation, before release to the network or to host. The officer sees what in this payment’s ISO/CBPR+ structure will stop it: a field, an absence, a cut if the path is still MT, a return code when one has already come back. Left: as received, frozen. Right: the working copy. Each finding is tied to a field.
The desk uses this installation’s library and rules — not a public-site pack and not a generative model. It may propose a lawful value from that library; it does not silently write the working message. Applying the proposal is an officer action (Accept structure proposal). Empty book → not_checked, never a fake OK. Sanctions / AML / PEP stay a neighbouring module — not a green tick on this desk. Outbound pacs.008 is formed from the book’s fields. If the correspondent still takes MT, losses are shown before send. The decision trail names the rule, the pack version, and who wrote the field.
The client terminal of this bank is the other end of the same suite: those clients send clean structured data (keys or pain.001); this bank forms pacs.008. Together, the client closes what they can see before send; the officer closes what the client cannot. Full explanation, formats, and the together picture: the bank page. Pilot on a copy of the flow needs no change to the payment path.
Consultant — questions about the terminal, bank connect, and MT→MX fields.
How it works
Three steps — check before you send
The check uses the library and the rules. The formed message is deterministic code — not model guesswork.
①
Fill in or upload
Payment details or invoice PDF — in your browser.
②
We check the standards
ISO 20022 / CBPR+ — route, IBAN/BIC, structured address, purpose code. You see 🟢 🟡 or 🔴 with a clear note on which field to fix.
③
Send via your bank
Fix what's flagged, pass structured data to your bank (keys or pain.001 file). The bank forms pacs.008 and posts the funds. Catching broken structure here avoids rejection and repair fees later.
Data layer · client to bank
Data layer between client and bank
The terminal forms clean structured payment data and passes it to the bank’s server — by keys, when a connection is configured. If there is no access, the terminal issues pain.001 as a file and the client delivers it to the bank. The terminal structures the message so the bank’s server can form pacs.008 for the network. Before that send, it shows which fields may fail in the bank’s processing. The payment is not kept as a client file on this public site.
📋
Structured by design
Address by fields, purpose as a code, mandatory identifiers filled — at the point of entry, not after rejection.
⚡
See before you send
Check the payment, change nothing in the bank — see 🟢🟡🔴 with a clear explanation of which field to fix.
🔬
Transparent for the bank
Output is a complete structured message — nothing truncated, nothing missing. Bank and client see the same clear fields before submission; the bank's translator has what it needs.
Smart Remittance Mapping
Describe the purpose in your payment details — get the right ISO 20022 code
The AI engine reads your free-text description (the old field-70 habit), proposes the correct Purpose Code, you confirm, and the XML keeps both your words and the structured code.
Codes are validated against the full open ISO 20022 ExternalPurposeCode list embedded in the core — no keys, no fees. Human-in-the-loop: the AI proposes, you always confirm.
