Reliable Payments with Nium Intelligent Routing

Globalisation and digitisation are inevitable evolutions of the modern world. Cross-border payments are at the core of all this international trade and economic activity. The cross-border payments market is projected to grow from $176.5 billion in 2021 to $238.8 billion in 2027, at a compound annual growth rate (CAGR) of 5.3% during the forecast period (reference). Legacy cross-border payment systems are unreliable and plagued with several shortcomings such as lack of transparency, multi-day (sometimes weeks) turnaround times and high costs.

There is a dire need for innovation in this space using technology and this is where FinTech's like Nium come to the rescue! At Nium we have systematically and strategically built a network which covers 100+ real time markets and supports 100 currencies. We have mastered the art of building integrations and have built over 75+ integrations with banks, payment service providers and direct clearing systems like SEPA in Europe and BCS- Direct Fast in Singapore. The platform processes over $25B+ in annual transaction volume.

To deliver a payment every market may need different data points and each integration or partner will have different validation rules in place to accept a transaction. And there are a number of different APIs, webhooks, and encryption/decryption techniques to be used which are specific to each integration. To summarize, there is a complete lack of standardization. APIs or File processing at the partner end could fail or there could be an outage which could be hardware related at the partner’s end. All this could cause delays in transaction processing with customer impact. For many use cases pertaining to payroll, medical emergency, or distress payments these delays may not be acceptable. The way this is currently managed is unreliable.  

Next Generation Payment Processor to the Rescue

At Nium we work hard to simplify the life of our customers, by providing an abstraction layer that hides the nuances and complexity associated with each payment corridor. This was a major simplification for our customers and since we always keep expanding our network as and when we added new markets, capabilities and alternate payment methods like wallets, cards etc., they were all available to our customers with the exact same integration.

Now that we had solved the standardization problem, we set our eyes on the next one. We wanted to maximize the number of successful transactions in the shortest time possible with the lowest operating cost possible and have redundancy to guard against partner outages. Yes, we wanted them all and so we built a next generation payment processor and armed it with a plethora of redundant partner integrations.

How it works: Intelligent Payment Routing

Nium’s next generation payment processor has a configuration driven rules engine where all dynamic routing rules can be configured. These routing rules have been setup to choose a partner integration based on the payment attributes and are optimized for high straight through processing rate and low cost. Once the rules engine decides on the payment partner, the platform simulates the execution using the partner to reduce the likelihood of a failure or a rejection downstream. The steps are below:

A) Payment processor will determine the appropriate payment transfer option e.g., SEPA instant vs Standard for EUR payments or checking NEFT vs IMPS vs RTGS for INR payments given the rules.

B) We run the validation rules that are specific to the partner integration. As part of the integration, we build those validations at our end, which actually run after we send a payment to our partner. Since we have those rules, we run them upfront as part of the dry run process.

C) We check if we have enough liquidity with our partner to deliver the payment at hand and any limits that may be applicable with the partner.

D) We check if the partner integration is healthy and up and running. If we detect issues like delayed processing times, unresponsive partner endpoints, we mark the partner as unhealthy.

Only when all steps are successfully complete for the chosen partner, then the payment will be sent to the selected partner. And there is more - we did our bit to make sure we chose the best partner with the least possibility of an error. But what if things still go wrong. We need a backup, don’t we?

With each of our integrations, we spend a considerable amount of time to painstakingly understand and map our partner error codes and decide next course of action. To give some context here a single partner API could have about 50 error codes on average and multiply that with 75+ integrations and that means a lot of translation and automation to automate errors and improve straight through processing times. If a partner responds with a definitive error stating it has not delivered this payment and has not debited our account, we safely look for an alternate partner in that corridor and then again run the same rules A-D and keep doing this until we either exhaust all our partner options or all partners give up on delivering this payment.

We have below major error classifications which indicate the next action the system needs to take on occurrence of these type of errors:

• Recoverable: Liquidity check is a type of recoverable error which is an example of point in time error. The system identifies recoverable types of errors and automatically retries them after a configured time interval and also notifies the treasury/operations team of the liquidity position.

• Retriable : Some beneficiary bank codes are not enabled to receive faster payments e.g., IMPS is not enabled for certain beneficiary banks in India. For these errors, the system will automatically switch the payment mode to NEFT and send on its own without manual intervention.

• Returns: Beneficiary account number frozen is one example of this type or error. In this case we auto-return these payments back to the customer.

Technology Under the Hood

We use Apache Camel extensively for all our partner integrations. This helps us standardize the way we do integrations. Our architecture is event-driven comprising of micro-services which run on containers in the cloud. We use RabbitMq as our messaging broker for dynamic routing along with Camel and use Hystrix and Circuit breaking for partner monitoring and traffic switching. We use Postgres as the relational database where all rule configurations are stored and use an in-memory cache for performance optimization.

So, was the effort worth it?

Yes absolutely! Here’s why:

1. Increased straight through processing rates.

2. More automation in auto-rerouting and handling of errors requiring minimum to no manual intervention resulting in lower transaction costs.

3. Unlocked untapped revenue potential to handle larger payment flows and reliability for time sensitive payments and opened new use cases.

4. Happy customers.

By SurajKumar Pal