Test Data, Environments and Simulators

Good test data looks like real payment data, but it must never be real customer data. A test pack for a pacs.008 change should include valid IBANs for the UK, Germany, France and Singapore, valid BICs for NatWest, HSBC, Deutsche Bank and DBS, and amounts that cover small, typical and large payments, such as 10 pounds, 25,000 euros and 950,000 dollars. It should also include edge cases, such as a payment of 0.01 pounds, a payment with a long remittance reference, and a payment in a currency that needs conversion. Realistic data finds defects that simple data misses. Test data must also be controlled and repeatable. Each test case should use a unique payment reference, such as TEST-2026-0147, so that results can be traced and duplicates can be detected. Test accounts should be clearly labelled as test accounts, with balances that support the test amounts, and with no link to real customer accounts. A tester who reuses the same reference for two different tests creates confusion, and a tester who uses a real customer IBAN in a test environment creates a risk that a test payment could reach a real account. Data discipline is part of payment testing, not an optional extra. Environments must be separated so that test activity can never reach production. A bank typically runs development, SIT, UAT and production as separate environments, with separate databases, separate queues and separate connections to SWIFT and clearing systems. A payment sent from UAT must go to a simulator, never to the live SWIFT network. Access to production must be restricted, and any data copied from production to test must be masked, so that account numbers, names and addresses cannot be read by testers who do not need them. Simulators play a vital role because a bank cannot ask another bank to test with it every day. A SWIFT simulator receives a pacs.008, validates it, and returns a pacs.002 acceptance or rejection, just as the real network would. A SEPA simulator returns a pacs.004 for a return, and a Faster Payments simulator responds within seconds with a confirmation. A good simulator also supports negative cases, such as a timeout, a duplicate message, or a rejection for a missing field. Without a simulator, a team would have to wait for external partners and could not test error handling properly. Test data and environment management also needs a clear process for refresh, reset and cleanup. After a test run, test accounts should be reset to known balances, queues should be cleared, and old test messages should be archived. If a tester runs a 100,000 pound payment test and the account is not reset, the next tester may fail because the balance is too low. A daily environment health check, a named environment owner, and a simple checklist for data setup will save hours of wasted effort and prevent false failures that hide real defects. Test data must be realistic enough to exercise the system and safe enough to never leak. A good test pack includes valid IBANs for the UK, Germany, France, and Singapore, valid BICs for the major correspondent banks, and payment amounts that cover the full range from 0.01 to 999,999.99. It must also include invalid data: an IBAN with a wrong check digit, a BIC that does not exist, an amount of zero, and a currency the corridor does not support. Each test case uses a unique reference such as TEST-2026-0147 so that results can be traced and duplicates detected. Real customer data must never be used, because a test environment is less protected than production and a leak would be a data breach. Simulators are what make payment testing possible at scale, because a bank cannot ask another bank to test with it every day. A SWIFT simulator receives a pacs.008, validates it against the schema, and returns a pacs.002 acceptance or rejection, just as the real network would. A clearing system simulator does the same for Faster Payments or CHAPS. The simulator must be configured to return the same responses as the real system, including the error cases, or the tests prove nothing. For a business analyst, the practical skill is to specify the simulator behaviour for each test case, including the exact response message, the exact status code, and the exact timing, so that the test proves the system handles the real world, not just the happy path.