Testing payment and SWIFT flows: where SA banking QA gets hard

Most software testing is about whether a feature works. Payment testing is about whether money ends up in exactly the right place, in exactly the right amount, in exactly the right currency, every single time, and whether you can prove it afterwards. That last part is what makes banking QA its own discipline.

We've spent 3+ years doing this work inside South African Tier-1 banks: card processing, multi-currency settlement, reconciliation, and SWIFT messaging. Here's where it actually gets hard, and how to automate it properly.

The stakes change everything

In a normal web app, a bug means a bad user experience. In payments, a bug means money in the wrong account, a failed settlement, or a reconciliation break that an operations team spends days untangling. The cost of a defect isn't a support ticket, it's rands moved incorrectly and real regulatory exposure.

That changes how you test. Coverage can't be "most of the paths." The money-movement paths need to be exhaustive, and the evidence needs to be auditable.

SWIFT messaging: structured, strict, unforgiving

SWIFT messages like MT940 and MT942, the statement and interim statement messages, are rigidly structured. Fields have exact formats, order matters, and a malformed message is either rejected or, worse, silently misinterpreted downstream.

Automated testing here means:

• Validating message structure against the format spec: every field, every tag, every length constraint.
• Round-tripping values. A balance that goes into a message must come out the other side identical. Floating-point drift and currency rounding are real enemies.
• Negative testing. Malformed messages, missing mandatory fields, and boundary values must be rejected cleanly, not processed into a mess.

This work is painful and error-prone by hand and ideal for automation, because the rules are precise and the volume is high.

Multi-currency settlement and the rounding trap

Settlement across currencies is where subtle bugs hide. Conversion, rounding, and the order of operations all matter, and the errors they produce are often tiny, a cent here, a cent there, which is exactly what makes them dangerous. Small discrepancies don't crash anything. They quietly accumulate until a reconciliation team notices the books don't balance.

Automated settlement testing has to assert on exact expected values, including the rounding behaviour, not approximate ones. "Close enough" is a defect in this domain.

Reconciliation is the real test

The honest measure of whether a payment system works is whether it reconciles: does every movement in match a movement out, with nothing lost, duplicated, or misattributed? Reconciliation testing ties the whole flow together, and it's where automation earns its keep, because reconciling by hand across thousands of transactions is slow, mind-numbing, and itself error-prone.

An automated reconciliation check can run the full set every build and flag the single transaction that didn't balance, in seconds.

Why automation matters more here, not less

Some teams assume payment flows are too critical or too complex to automate and keep them manual. That reasoning is backwards. The higher the stakes and the more exhaustive the required coverage, the stronger the case for automation. Humans are inconsistent across thousands of repetitive checks; that's precisely the condition where errors slip through. A well-built suite tests the same thing the same way every time, which is the entire point in a regulated environment.

The approach that works, drawn from real Tier-1 engagements, pairs API-level validation of the messaging and settlement logic with end-to-end checks on the card and payment journeys, all wired into CI so the money paths are re-verified on every change. In one engagement this removed roughly 95% of the manual regression effort while *increasing* confidence in the flows that mattered most. We've written up the maths behind that separately.

The standard for payment QA

If you're testing payments, hold the work to a higher bar: exhaustive coverage of money-movement paths, exact-value assertions including rounding, strict SWIFT structure validation, automated reconciliation, and an audit trail that proves it all ran. Take nobody's word that the payment flow is fine. Make the suite prove it, on every release.