← All guides

Why a schema-valid pain.001 file still gets rejected: bank implementation guidelines (MIGs) explained

The three rule layers behind every bank rejection — ISO schema, scheme rulebook, and the bank’s own implementation guidelines — and how to work with the layer nobody publishes in the standard.

It is the most confusing sentence in payment operations: the file is valid, but the bank rejected it. Both halves are true. The file passed the ISO 20022 schema — its structure is legal, its elements are in order, its values have the right shapes. And the bank still said no, because the schema is only the first of three rule layers that govern a real payment, and the other two layers are stricter. The third layer, the bank’s own implementation guidelines, is the one that surprises everyone, because it is not in the standard, differs from bank to bank, and changes on the bank’s schedule. This guide explains all three layers, what a MIG actually is, and how to stop being surprised by rules you cannot see in the schema.

Layer one: the ISO schema — necessary, nowhere near sufficient

The XSD schema published with each ISO 20022 message is a grammar. It defines which elements exist, their order, which are required by the standard itself, and the datatype of each value. It is deliberately permissive in the places where real-world usage legitimately varies: a field the standard marks optional may be unused by one community and essential to another. The schema also cannot express arithmetic or cross-field rules at all. It cannot say that the header total must equal the sum of the payments, that this code must be SLEV for euro payments, or that this account number’s check digits must divide correctly. A schema-valid file is a file that is shaped like a payment message. That is a real achievement — malformed files are common — but it is the entry ticket, not the exam. Anyone who has only ever run a generic XML validator has only ever checked layer one.

Layer two: the scheme rulebook — where business rules live

On top of the grammar sit the rules of the payment scheme the file travels under — for euro credit transfers, the SEPA Credit Transfer rulebook maintained by the European Payments Council. A scheme is a contract among banks: they agree to process payments that follow one shared, narrower profile of the standard, so that any bank can handle any other bank’s files. The narrowing is the point. The scheme fixes the currency to euro, the charge bearer to SLEV, the character set to a safe list, the remittance length, the execution-date logic, and dozens of presence rules: this optional element is mandatory here, that one must not appear. None of that is in the XSD; all of it is enforced. Most rejections that confuse ERP teams live in this layer, because the file looks impeccable to every tool that only knows the standard. Our checks implement this layer explicitly — the SEPA rules in our validation walkthrough are layer-two rules.

Layer three: the MIG — your bank’s private profile

MIG stands for Message Implementation Guide (you will also see implementation guidelines, or market implementation guidelines for a whole country’s banking community). It is the document in which a bank — or a national community — writes down its own further narrowing of the scheme profile for the channels it operates. Typical MIG content: the pain.001 versions accepted on this channel; which optional elements the bank requires, ignores, or forbids; maximum payments per file and per batch; file size limits; cut-off times and the calendars that apply; how the debtor account must be identified for mandates and permissions; whether batch booking is supported and how it must be flagged; and the exact channel quirks of the portal, EBICS or API you upload through. Two banks in the same country, both fully SEPA-compliant, will have MIGs that differ in a dozen such details — which is why a file can be accepted by one and rejected by the other without either bank being wrong.

Why do banks narrow further at all? Because a scheme guarantees interoperability between banks, but each bank also has its own core systems, fraud controls, channel limits and support burden. An element the scheme allows may be one the bank’s core cannot store; a batch size the scheme tolerates may exceed what the bank’s portal was built for; a version the scheme retired years ago may linger in the MIG of a bank that still supports legacy customers. The MIG is where the portable standard meets one institution’s reality. It is also a living document: banks publish updated guidelines ahead of scheme change dates and their own system releases, and the updates are easy to miss because they arrive as PDFs on a developer or corporate-banking page nobody monitors. Many mystery rejections are simply a MIG change that took effect while your template stood still.

How to work with a layer you cannot fully see

You cannot validate against a document you do not have, so the first move is possession: download your bank’s current pain.001 implementation guidelines for your channel, note the version and date, and store them with your payment-run documentation. Ask your relationship team two questions in writing: which pain.001 versions do you accept today, and where do you announce guideline changes? The answers prevent the two classic MIG surprises — the retired version and the silent rule change. Repeat for every bank you send files to; in multi-bank setups, the strictest MIG effectively becomes your house standard, because a template that satisfies the strictest bank usually satisfies the rest, while the reverse is not true. Vendors learned this long ago, which is why mature exporters target a conservative profile: only elements and patterns that are safe across the banks their customers use.

The second move is forensic. Keep the last file each bank accepted. When a rejection arrives with a vague message, compare the rejected file with the last accepted one, element by element, before changing anything. The difference set is small — a new element from an ERP update, a field that moved, a limit crossed by growth — and the culprit is almost always inside it. This works because MIGs reject novelties: a file identical in shape to one that was accepted last month is, by construction, inside the bank’s profile, whatever changed in the data content. The accepted file is your empirical MIG, the ground truth of what this bank takes from you, and it is worth more than any amount of standard-reading. Our overview of common rejection reasons includes this comparison trick among its first checks for a reason.

• Keep each bank’s current MIG, its version and its change announcements with the payment documentation — and a calendar reminder to re-fetch them twice a year.
• Keep the last accepted file per bank as your empirical baseline; diff any rejected file against it before touching templates.
• Build templates to the strictest bank you use; do not maintain per-bank dialects unless a MIG truly forces one.
• Treat ERP updates as MIG events: after any change to the exporter, validate a sample file and compare its shape with the accepted baseline.
• When support asks for an example, send the MsgId and the exact element in question — MIG questions have precise answers when the question is precise.

What this means for validation tools — honestly

A validator can fully cover layers one and two: the official schemas for every version, and the scheme’s business rules — totals, check digits, character set, charge codes, reference formats, uniqueness. That is what we built, and you can run it free on the home page to see exactly which layer each finding belongs to. Layer three is different: no independent tool can claim to know every bank’s private profile, and you should distrust one that says otherwise. What a tool can do is shrink the surprise: catch everything the first two layers contain so the only remaining failures are genuinely bank-specific, and make those failures cheap to diagnose by giving you exact locations to compare against your accepted baseline. On the paid plans, batch validation and exportable reports help multi-bank teams keep that evidence per bank and per run — see pricing — which turns the next MIG surprise into a short diff instead of a long day.

The in-between layer: country and community profiles

Between the scheme and the single bank sits a fourth actor worth knowing about: the national or community profile. Banking communities in several countries publish a shared implementation guideline that all their banks follow — the German DK community’s specifications are a well-known example, and the CGI-MP initiative plays a similar harmonising role for corporates banking with many institutions across borders. These profiles exist to spare everyone the worst case, in which every bank’s MIG is a fresh surprise: if a country’s banks narrow the scheme the same way, one community document describes them all. Practically, this means your research order when onboarding a new bank should be: scheme rulebook first for the shared rules, community profile second if the bank’s market has one, and the bank’s own MIG last for the residue that is truly private. It also means a template built for one German bank is a better starting point for another German bank than a template built for a bank in a different community — the middle layer travels with the market, even when the top layer does not.

The in-between layer also explains a pattern that otherwise looks like coincidence: a file rejected by two banks in the same country for the same unstated reason. Teams sometimes read that as an industry conspiracy or a scheme rule they missed; it is usually the community profile, enforced uniformly by banks that share it, and discoverable in one document once you know it exists. When you hit the same wall twice in one market, stop reading individual MIGs and ask the community question: is there a national implementation guideline for pain.001 here, and are we built to it? One document later, the mystery usually ends.

If you are choosing or building tooling, the layers give you a sharp question to ask any vendor, including us: which layers do you check, against which documents, and how do you keep them current when the scheme publishes a new rulebook version? A tool that answers with the schema alone is selling layer one as the whole building. A tool that claims to know every bank’s MIG is selling confidence it cannot possess. The honest middle — full schema coverage for every version, the scheme’s business rules implemented explicitly and versioned with the rulebook, and clear reporting that separates the two — is what actually reduces rejections in production. Judge tools by the findings they produce on your own worst file: upload the file your bank rejected last quarter and see whether the report names the rule that killed it. That single test distinguishes the layers in practice better than any feature list, ours included.

The mental model to keep is the pyramid: a broad, public grammar at the bottom; a scheme’s shared contract in the middle; one bank’s private profile at the top. Valid is a word that only makes sense with a layer attached. When someone says a file is valid, ask: at which layer, checked by whom, against which document, on which date? Teams that ask those four questions stop being surprised by rejections, because they have mapped the territory where surprises live. The schema was never lying to you. It was just never the whole truth — and now you know where the rest of the truth is kept, and how to keep your own copy of it.