BankLint

Guides · By Tan Gravam · Updated 2026-10-20

Testing payment files before going live with a bank

Before a new bank connection, payment method or ERP release goes live, prepare one test file per payment route, validate each against the ISO 20022 schema and the SEPA rules yourself, then send it through the bank’s test channel until it is accepted. Keep the accepted file as the reference: every later file can be compared with it.

What the bank tests, and what to test first

Banks usually test new customers and new formats in a test environment and answer with a status report (pain.002). Each round takes time, so schema errors and SEPA rule breaks found in the bank’s test are an expensive way to find them. Check these yourself first and use the bank test for what only the bank can confirm: its own file specification, its channel and the accounts.

Test files to prepare

  • One file per payment route: each payment method, house bank account and company code that will send files.
  • The message version the bank expects: pain.001.001.09 or the older pain.001.001.03 (see the differences).
  • A file with several payment information blocks, if your payment run splits by date, account or batch booking.
  • Boundary values: a 70-character creditor name, 140 characters of unstructured remittance, a structured RF creditor reference, the smallest and a large amount.
  • Addresses in the form you will send: fully structured is what the EPC recommends (structured addresses).
  • A payee in a non-EEA SEPA country such as Switzerland or the United Kingdom, if you pay any: it needs the debtor address with country.
  • Names and remittance text with the national characters your vendors use, if your bank accepts them (character set).

Before sending each test file

  • Validate it: no FAIL findings. A FAIL is a blocker the bank is likely to reject. Use the validator or the synthetic samples to see what each finding looks like.
  • Resolve every REVIEW finding against the bank’s file specification: these depend on your agreement with the bank.
  • Give every file a new MsgId: banks reject a message identification they have already received.
  • Check the requested execution date against the test window the bank gave you.

Getting the first accepted file

Send the files through the bank’s test channel and read the pain.002 for each one. A rejection names a reason code: the pain.002 reason code guide maps the common ones to their usual cause in the file. Fix the mapping, generate the file again from the source system (not by editing the XML), and resend.

When the bank accepts a file, keep that exact file and note the date, the bank’s confirmation and the configuration that produced it.

Keep the accepted file as the reference

The accepted file is the most useful test artefact you have: it is proof of what the bank takes. In BankLint, validate it in a Flow and make it the baseline. After go-live, every change in the source system can be checked by validating the next file in the same Flow: BankLint shows what changed in the configuration compared with the accepted file. See payment-file regression testing.

What changes files after go-live

  • ERP support packages and upgrades that change the delivered payment formats.
  • Changes to the format mapping (in SAP, for example, the payment medium format and its mapping tree).
  • House bank, payment method or company code configuration.
  • Vendor master data: addresses, names and bank details.
  • Middleware or bank-connectivity mapping between the ERP and the bank.
  • A move to a newer message version required by the bank.

Questions

How many test files does a bank need before go-live?

It depends on the bank. Usually at least one accepted file per payment method and format, and often per company or account. The bank’s onboarding team states what it needs.

Should test files contain real payment data?

Use the test data your bank asks for, in its test environment. For checking structure and rules, synthetic data works just as well: BankLint processes files in memory and does not store them.

Can I edit the XML to fix a rejected test file?

Only to understand the problem. The fix belongs in the source system or mapping, otherwise the next generated file has the same error.

Sources: EPC132-08 2025 Version 1.0 (European Payments Council) and the ISO 20022 message schemas. All sources and dates: Standards and sources.

Validate a pain.001 fileFree, no account needed, files are not stored.