Rethinking payment simulation:
the hidden blocker in your go-live process

For financial institutions, payments are central to how their products operate and how they generate revenue. Payments encompass a variety of processes, including credits and debits, refunds and returns, as well as recalls and rejects. These transactions can span multiple schemes, systems, and partner banks, each with its own set of rules and message formats. Missing even a single detail can result in failed transactions, delays, and ultimately dissatisfied customers.

So when preparing to go live with a new technology provider, customer, or partner, the key question is simple: can your systems handle all of these payment processes? That’s where payment simulation comes into play.

The role of payment simulation

When establishing your payment infrastructure, testing is not an afterthought, but a critical part of the launch process. Before a provider goes live with customers, they must follow a series of steps to ensure their systems are ready for production. These steps typically include internal quality assurance (QA), onboarding checks, and User Acceptance Testing (UAT).

At each of these stages, payment simulations allow teams to observe how their systems perform under realistic conditions. This includes ensuring that payments are processed correctly, balances are updated as expected, edge cases do not disrupt workflows, and status updates are delivered to the intended endpoints. Additionally, payment simulations prepare teams to meet formal test‑case requirements across various schemes and partner banks (e.g., SEPA and Swift).

Despite its importance, payment simulation remains a common challenge. It is often one of the main reasons that testing phases take longer than planned, which can ultimately delay launch timelines.

Why payment simulations often slow down go-live

Payment simulation may seem straightforward – just send a message to trigger a result – but the reality is much more complex from a technical perspective.

To simulate payments, teams often need to:

• Manually prepare XML files (structured message formats used in SEPA and Swift payments) that must adhere to strict ISO 20022 or EPC guidelines

• Handle status transitions that reflect the behaviour of payment schemes (e.g., from pending to executed and rejected)

• Build and test object relationships, such as linking payment orders to internal accounts, balances, and counterparties

• Coordinate simulation steps across different environments, teams, and sometimes even with external partners.

This level of complexity means that simulation often relies heavily on engineering or delivery support. In some cases, quality assurance or onboarding teams depend on shared documents, sample files, or Slack threads to simulate even a single payment flow.

The outcome is predictable: an increase in back-and-forth communication, slower onboarding processes, extended UAT cycles, and ultimately delayed go-lives. The business implications are particularly significant for financial institutions, which face consequences such as lower customer activation rates, delayed revenue, higher onboarding and support costs, and increased challenges when scaling go-live operations across different regions or partners.

The problem with most available simulation tools

To address these challenges, many platforms have developed simulation tools for their customers. However, most of these options are designed around basic use cases and often fall short when it comes to B2B or interbank flows.

Common limitations include:

• Amount-based triggers: Simulations that are solely focused on sending a specific amount, lacking deeper context

• Webhook-only responses: Limited visibility or control over how scenarios unfold

• Retail-oriented logic: Tools designed exclusively for card, consumer, or peer-to-peer use cases

• No object relationships: Events are not linked to real entities such as payment orders, internal accounts, or balances

• No message integrity: Insufficient support for standard-compliant XML messages or scheme-specific transitions

While these tools may be adequate for testing individual events, they are not suitable for the structured, repeatable, and standards-aligned testing required during User Acceptance Testing or onboarding for enterprise-grade payment flows. As a result, teams often end up building their own simulators or, worse, relying on actual banks to trigger and confirm flows, which introduces additional delays and dependencies beyond their control.

A simulator designed for production-grade testing

Mambu Payments' bank simulator was designed to overcome existing limitations in payment testing. Utilizing the same internal XML engine as production (without the use of mock data or random payloads), it offers a realistic sandbox environment for simulating SEPA and interbank flows, while ensuring object-level integrity – a feature particularly important for B2B payment operations.

In practical terms, the simulator allows users to test real-world payment flows by either running built-in scenarios or uploading bank or CSM messages.

The built-in scenarios can be accessed via the API and the dashboard, allowing users to simulate various events such as creating incoming payments, updating payment statuses, or creating balances and transactions. These scenarios are beneficial for quickly testing common events without the need to prepare custom files.

Message upload is only available through the API, supporting standard XML messages, Swift MT messages, and Bacs Standard 18 messages. This mode is ideal for testing specific or complex flows that require precise message content, adhering to the standardized file structures used by banks and schemes to exchange payment instructions and status updates.With the bank simulator, QA teams, onboarding managers, and delivery teams can:

• Test actual transitions (e.g., executed, rejected, pending) using actual EPC reason codes rather than just simple “success/fail” toggles.

• Validate relationships between payment orders, accounts, transactions, and balances

• Provide QA, onboarding/delivery, and engineering teams with clearer and faster feedback loops

In summary, the outcome is straightforward: faster onboardings, more efficient UAT, fewer support handoffs, and much shorter go-live timelines.

If you’re interested in exploring Mambu Payments’ bank simulator in more detail, read our bank simulator guide.