ISO 20022 Payment Format Builder

The problem

ISO 20022 is a standard the way a passport is a standard: everyone agrees on the shape, and every border guard has their own opinion about it. One bank rejects a pain.001 because the debtor address is structured rather than unstructured. Another requires a specific CtgyPurp code on every domestic credit transfer. A third caps RmtInf/Ustrd at one occurrence and silently truncates the second. A fourth wants the batch booking flag set the opposite way to the other three.

Inside Finance and Operations, this turns into a recurring project. Each new bank, each new country, each new payment type means another Electronic reporting configuration derived, mapped, tested against a sandbox file, rejected, corrected, and tested again. The knowledge lives in one consultant's head or in a chain of derived ER configurations nobody wants to touch.

The return leg is usually worse. pain.002 acknowledgements arrive and get read by a human, if at all. camt.054 debit and credit notifications sit in a bank portal instead of clearing the payment journal. Treasury finds out a payment failed when the supplier calls.

What ECOSIRE builds

We build a configurable payment format layer for Finance and Operations covering both directions — outbound payment instruction generation and inbound status and notification processing — using the Electronic reporting framework where it belongs, and an X++ extension model for the orchestration, validation and reconciliation that ER alone cannot do. No overlayering.

Outbound: payment instruction generation

We derive and configure Electronic reporting format and model mapping configurations for each of your banks, based on their published implementation guidelines, covering the message types you actually send — typically pain.001 for credit transfers and pain.008 for direct debits where relevant.

The bank-specific behaviour is held in a bank profile rather than scattered across configurations: character set restrictions and transliteration rules, field length limits, structured versus unstructured party addresses, batch booking behaviour, service level and local instrument codes, charge bearer defaults, and how remittance information is assembled from your invoice references.

Payment generation runs from the standard vendor payment journal and the payment method setup, so your AP team's process does not change. Files are produced through the electronic payment format on the method of payment, with the bank profile selecting the correct configuration and behaviour by legal entity and bank account.

Pre-submission validation

This is where most of the pain actually goes away. Before a file is written, a validation service checks the payment run against the destination bank's rules: mandatory IBAN and BIC presence and checksum, creditor address completeness for the corridor, currency and country combinations the bank will not accept, forbidden characters, amount and line-count limits, duplicate end-to-end identifiers, and blank or malformed remittance references.

Failures are reported per payment line with a plain description of what the bank will object to, so AP fixes them in F&O before the file goes anywhere. A file that passes validation is a file the bank should accept.

Outbound: identifiers and traceability

End-to-end identification, payment information identification and message identification are generated under configurable, non-repeating schemes and stored back against the payment journal lines. That is what makes the return leg possible — every acknowledgement and every statement entry can be traced to the exact F&O payment it belongs to.

Inbound: status and notification handling

An import service picks up bank responses from your chosen transport — an SFTP location, an Azure storage container, or a folder monitored by your integration platform — and processes them on the batch framework.

• pain.002 payment status reports are parsed to group and transaction level. Accepted, pending, and rejected statuses are written back against the originating payment lines with the bank's reason code and its human-readable meaning. Rejections raise an alert rather than sitting in a log.
• camt.054 debit and credit notifications are matched to payments by end-to-end identifier, and to customer receipts where you are using them for incoming funds.
• camt.053 end-of-day statements can be brought into scope for bank reconciliation, with entries mapped to the advanced bank reconciliation matching rules so your existing reconciliation process consumes them.

Everything imported is stored with the raw message retained, so an auditor or a bank support ticket can be answered from inside F&O.

Ledger, dimensions and multi-entity

Bank profiles, configurations and transport settings are set per legal entity, so a shared service centre running payments for many companies gets the correct format per company and per bank account without cross-contamination. Postings respect your ledger account and financial dimension setup — rejections reverse cleanly against the same accounts and dimensions the original payment used.

Operations

A workspace shows payment files generated, their submission state, acknowledgements received, unmatched notifications and validation failures awaiting correction. Batch jobs for import and processing run under the standard batch framework with alerting on repeated failure.

Who this is for

Finance and treasury teams running Finance and Operations who pay through more than one bank, or in more than one country, and who are tired of every new bank relationship becoming an ER configuration project. It is particularly relevant where you are moving from proprietary flat-file formats onto ISO 20022, or where a bank has issued a migration deadline.

How delivery works

Scoping call. Bring your banks' implementation guidelines. We go through each bank, each message type, each country corridor, your legal entity structure, your F&O version, and how you want returns to post. This is the single most important step — the guidelines determine the build.

Fixed quote. You get a written scope naming every bank, every message type, the validation rules in scope, and a fixed price and delivery window. Nothing starts until you approve.

Build. We develop the ER configurations and the extension model against your version, and test generated files against the bank specifications. Typical build is two to four weeks depending on how many banks and message types are in scope.

Install in test. Deployed to your sandbox through your LCS or Azure DevOps pipeline. We generate real payment runs from your data and, where your bank offers it, submit them to the bank's test channel so acceptance is proven before go-live.

Production. Promoted on your change window, typically alongside a first live payment run we supervise.

Support. A support window follows go-live for defect fixes and bank-feedback corrections. Source and ER configurations are handed to you.