Choosing a payment switch: questions to ask before the RFP

A payment switch sits at the heart of a bank for a decade or more. Choosing one is as much about how you will live with it as about what it can do on the day you buy it.

Start with your own requirements

Before issuing a request for proposal, agree internally what the switch must do: the channels it must serve, the schemes and networks it must connect to, the transaction volumes you expect in five years, and the services you want to launch. A clear statement of need keeps the evaluation focused on your bank rather than on each vendor's favourite features.

Coverage and standards

• Which card schemes, domestic networks and payment systems are supported today, and which are certified in your market?
• Which ISO 8583 variants and which ISO 20022 messages are supported, and how are new mandates delivered?
• How are channels such as ATM, POS, e-commerce, mobile and SMS connected?

Resilience, not just speed

Throughput figures are easy to quote and hard to compare. Ask instead how the switch behaves under stress. How does it scale for peak days? Can it run active-active across sites? What happens to transactions in flight during a failover? How does stand-in processing work when the core banking system is unavailable, and how are those transactions posted afterwards?

Integration with your core

The cost of a switch is often decided by its integration with your core banking system, not by its licence. Ask for real examples of integration with your core platform, how account and limit checks are performed, and how reconciliation between the switch and the core is handled. Pre-built connectors are valuable only if they match how your bank actually operates.

Security and compliance

Confirm how the vendor supports PCI DSS requirements, how keys are managed and which hardware security modules are supported, how sensitive card data is protected, and what audit trails are available. Ask how security patches are delivered and how quickly.

Operations

Your operations team will use the switch every day. Look at monitoring and alerting, dispute and chargeback handling, reconciliation and settlement reporting, and how parameters and configuration changes are controlled and approved.

Commercials and the long term

• Licensing: per transaction, per channel, per institution, or a fixed fee, and how it changes with growth.
• Change requests: how customisation is priced and how long it takes. This is where many budgets slip.
• Roadmap and support: the vendor's plans for the product, local support capacity, and the strength of their user community.

Prove it before you sign

Speak to reference banks of a similar size and region, and ask what they would do differently. Where possible, run a proof of concept with your own scenarios, including failures, not just a vendor demonstration. Finally, compare the total cost of ownership over the full life of the switch, including integration, hardware, certification, support and the internal team needed to run it.