Simplified integration with Nium using SWIFT message standards
Banks and financial institutions are increasingly appreciating the benefits of moving away from expensive, slow and opaque international wire transfers to lower cost, faster and predictable local payment rails using Nium’s modern APIs. However, we understand that integrating with a new set of APIs requires significant technology investments due to different message formats and connectivity/security standards. Local payout rails also require beneficiary details (e.g., local routing numbers) that are often not collected from international beneficiaries today.
To address this challenge, Nium is working across many levels to make this transition much simpler for the industry. While our APIs already support local payouts in 50+ currencies using the standard SWIFT codes or IBANs, we are soon making it even simpler by enabling banks to simply send us the existing SWIFT formatted payment messages and letting us convert & map those to the Nium API and process as local payouts.
Challenges with global payments today
In today’s cross border payment space, the correspondent banking system holds sway, facilitating vast volumes of transactions across borders. That said, participants contend with a range of issues: lengthy and unpredictable transaction chains, lack of visibility into foreign exchange conversions, confusing and variable fees, and fragmented validation and compliance checks.
Whether you’re a sender or receiver, a poor payments experience results in:
More expensive transfers
Inconsistent Settlement Times
Nium’s value proposition
With a single integration to Nium’s modular APIs, financial institutions can access payout coverage across 190+ countries with a combination of local bank transfers, card payouts and digital wallets, with 100+ real-time markets. These are the key benefits for customers:
Transparent Fees: Clear view of final fees charged and amount beneficiary will receive.
Cost Efficiency: Cost savings via Nium’s competitive rates and avoiding fee loss via multiple intermediaries
Faster Settlement: Faster, more consistent payout timing
Optimized Routing: Greater transparency into your transactions, making use of Nium’s chronometer and intelligent routing.
Reliability: Nium handles upfront validation and transaction screening and directly routes to local markets. This avoids passing through intermediaries where there is a higher potential for validation failures, missed cutoff times, etc.
However, switching away from the existing international wire transfers to such local rails comes with the following challenges:
Banks/FIs need to modify their end user flows to collect additional details (e.g., local bank routing numbers & additional data elements required by local schemes, vs. the standard SWIFT Codes/IBANs they use for wires). This introduces significant friction in the user experience, and sometimes may not be possible (e.g., when the beneficiary details are simply read from a supplier’s invoice).
The technology stacks at most banks and financial institutions have been built on top of industry standard formats like SWIFT MT (e.g., MT103 for payment processing, MT940 for statements). Bank technology budgets are already under pressure as they have to move to the new data rich ISO20022 standard before 2025 - and ISO20022 is incredibly detailed. Mapping these fields to a more streamlined API structure can be tedious and complex. In these conditions, making a custom integration to a proprietary message format is understandably hard.
SWIFT provides a universal connectivity and security protocol for banks to message each other with payment messages. Adoption of a different standard adds to the switching costs.
Nium already solves the problem associated with the data collection by enabling local payouts in 50+ currencies using the standard SWIFT codes or IBANs that are traditionally used for international wire transfers.
However, we understand that adoption of new message formats is also a significant challenge. Nium is here to ease the transition, with minimal friction. And when we say 'friction,' we're really zeroing in on it. Our APIs are simple and intuitive, but we recognize that many FIs are either already deeply entrenched within the ISO 20022 world, or they are in the process of transitioning. Most of their analysts, product managers, and engineers are already well-acquainted with these standards.
Coming soon, you can integrate with Nium using ISO20022 standard messages (e.g., pacs.008 for payment clearing/settlement, pacs.002 for status, camt.053 for statements), and we’ll convert these to the Nium API and process them as local payouts in 50+ global market. Send us your existing payment messages to an API endpoint, with existing IBANs and SWIFT codes, and we’ll handle the heavy lifting. Faster, cheaper payouts, without the technical overhead.
The ISO 20022 opportunity
The relationship between FI’s and standards such as ISO 20022 (MX messages in SWIFT) is a bit of a love hate relationship. While it promises rich, structured data and a chance at improved straight-through processing rates, it also demands FIs to quickly learn and adapt downstream systems to this new language. SWIFT's transition mandate to ISO 20022 by March 2025 only intensifies this challenge.
By enabling interactions with Nium via the ISO 20022 standard, we’re recognizing the importance of this standard, and granting customers a straightforward gateway into the Nium payment network, along with all the benefits that it entails.
Our goal is to keep chipping away at these adoption challenges one by one, and we will continue to find innovative ways to help our customers leverage the power of our network. As we work with some of our pilot partners to launch this solution, we are keen to hear from more customers about their unique set of challenges. We will also soon share more details about how we are solving some of these challenges at all levels of the technology stack, so that the industry can bridge this divide and seamlessly integrate into the world of global wires and domestic payment rails.
By: Dharminder Singh and Drew Humes