TenureXResourcesCase studiesThe Promise of Unbundling a Wire to an API
The Promise of Unbundling a Wire to an API

The Promise of Unbundling a Wire to an API

One of the most important catalysts for the recent growth in financial and banking services has been new age digital banks and financial institutions enablers using new infrastructure built on top of new regulation layers (E-money Directive and PSD2 Open Banking as the European examples).

Partner banks, chartered institutions that provide fintech companies access to banking products, have exploded, their ranks have grown more than five times over the past decade. TenureX aims to provide greater visibility into this interconnected and expanding ecosystem: the partner banks, the fintech companies, and the many services these partnerships can offer for small businesses.

Companies like Plaid wrap otherwise byanztine legacy technological banking processes and infrastructure in modern APIs, allowing every developer to easily integrate compliance and payments with software products, often to the great benefit of consumers.

In addition, the new trend of API providers is moving from a read-only modality to read-write model. This gives rise to new use cases: Send Card Payment APIs can provide data furnishing (read/write), in addition to payment fraud monitoring (read only).

In this paper, we outline our thinking on unbundling a wire into an X-ray view served on an API including the best model for market entry and the long term outlook for these companies at scale.

The promise behind single wire transfer data

Every wire transfer holds two essential attributes/components; The money handling attribute/component and the Liability component. We can think of the money handling component as the Shipping Details of a package and of the Liability Component as the Custom Duties that are applied per the content of the package.

We have seen a slew of great new companies offering solutions that are based and leveraging the “Shipping Details” of a wire transaction, efforts like Swift GPI, and ISO 20022 are the most known.

As for the Custom Duty side of the wire transaction, where the data is about the content of the package, we witness a monochromatic approach in the ecosystem in a form of AML and Compliance systems keeping data in silos.

To date, the actual data about the “content of the package” has only been partially visible to banks and financial services providers in silos, a fragmented, unstructured and peripheral way.

The data of the payee and payer, their relationships, their history with their banks, the reasons behind the transfer, and other attributes essential to understand if the goods inside the box are actually a “gift” and not a “bomb”.

To all the FIs participating in the chain and taking the liability in doing so, the goods are known just upon unboxing the package.

This data is important because it gives visibility into a wire-transfer’s actual overall liability (compliance, liquidity, AML/CTF risks) potential to all participants before the box is being shipped. Now all parties can think of “how, and with whom to execute and in which price”

Through sophisticated data science and machine learning, we can now unlock more data sources to better assess risk for FIs who lack sufficient data or are ‘brand invisible’ in the current ecosystem. Today, we’re swimming in far superior data than ever before.

Unified access to wire transfer data holds promise for financial institutions, banks & neobanks, financial services, and B2B fintech companies in distinct and interesting ways.

Liquidity Providers Fintech Companies Banks and NBFIs
A data driven asset type. Explore new volumes, relationships and partners. Explore new volumes, relationships and partners.
Enrichment of underwriting model. Improve banking offering while reducing time to market. Improve banking offering while reducing time to market.
A scalable framework Increase customer retention, improve experience and LTV. Increase customer retention, improve experience and LTV.
Contribute back landing data to the system. An external and scalable framework to replace non core internal functions. Programs to meet RBA requirements.

Liquidity Providers can become integrale players in the daily management of cross border wire transfers market between banks (vostro/nostro relationships) and be better at both underwriting and servicing these financial institutions.Most immediately, liquidity providers can now give credit and cover shortages of liquidity buffers between accounts much more quickly and easily than existing methods for doing so.

Further, when a liquidity is granted per single wire transfer, per industry, corridor and much more, it de-risks the credit risk significantly.

This sort of “new liquidity market” can open new income channels for liquidity providers and allow them to underwrite to a broader set of markets.

In addition, when liquidity providers are entering this market, it has the potential to reduce fraud, improve service quality, and decrease fees and prices for the end-customer. This is particularly important for small banks, financial institutions and startups in the cross border wire transfers space, since they are very concerned about the collateral they are required to keep in each banking partner.  Foreign and bigger banks are less likely to serve lesser known banks, financial institutions or startups. The ability to receive unified data and to set up clear mitigation rules, puts liquidity providers in a new revenue stream.

SME/Business fintech companies can increase LTV by offering their consumer’s multi currency account and ability to seamlessly receive or send wire transfers as well as mitigating their counterparty risks (the relationships with their banking partners). When neobanks and other deposit-taking institutions connect to wire transfer data and banking partners, the neobank gives their consumers the ability to safely, efficiently and cost effectively route in and out all their deposits to the same institutions.

There are several benefits to that, namely, full visibility to wire transfers hitting their customers’ accounts before the banks, rather than relying on the banks’ monitoring systems and processes . This dramatically increases the fintech company’s share of spend and LTV, as essential revenue engine for neobanksand through transfers’ volumes, FX, cross border wire transfers..

Finallybanks and NBFIs are better equipped to expand their market share and provide institutional banking services to a higher number of customers and more granular types of customers.

It is a strange anachronism that while financial institutions and other banks are the banks’ primary segment of source of income, they are perceived as higher risk for the banks, being heavily scrutinized, and being de-risked time after time.

As the trend of neobanks, deposit taking accounts and FinTech will continue, banks will have to increasingly but holistically offer their services to their most valuable customer.

Most banks currently build coverage of their institutional banking customers through a combination of third party software solutions and direct integrations (mainly for AML/KYC transaction monitoring). The former is easier to set up, while the latter is more reliable. Either way, high coverage, and ability to manage liability is the necessary admission fees to be a player in this space.

The trade-offs of various wedges

There are four main approaches here. Each has opportunities and challenges.

Correspondent banking

This entry point has a number of interesting attributes. First, there’s an opening to solve an overwhelming large problem in this space. The classical Corresponding banking services (e.g. a bank servicing another foregin bank’s wire transfers) is a known (and unloved) legacy business that is the engine of one of the biggest markets in the world, the cross border transfers. This $100b in revenues market (see accenture report) is being criticized by the association and countries (FATF, G20, BIS), but still untouched in the day to day level by regulators and legislators. Despite being manual, low-tech, and full of frictions, the business generates for banks and the payments grids (SEPA, Swift for example) billions in revenues each year, making for a well-understood TAM that a startup can go after with the usual playbook: attacking a very big problem with tech innovation (digitalization) that has an enormous profit pool.

Second, there is the potential for market expansion. Though corresponding banking services are typically offered by large international banking groups, they are not yet matured in small-medium banks. Adding the Wire Secure API tool should improve the ability for this segment to offer this service and generate additional revenue stream for its shareholders, thus increasing market size for the product.

The challenges with this approach are:
Lack of customer urgency – Incumbents banks as customers have little incentive to innovate within a niche business unit. Better management of corresponding banking, while valuable, does not unlock an immediate and significant pain, implying a long sales cycle.

Regulatory hurdles – Cyber and Information Data Security standards and regulations can be an additional hurdle to overcome within this market, and the ways in which it shall be protected and used by.

Competing models – Though more accurate and augmented data could improve corresponding banking services by the banks, many newcomers currently have models for how to overcome the basic problem and friction by using new blockchain technology. For example, Rippel and Visa B2B Connect, offer cross border transfers to people and businesses claiming that they are better than the traditional Fiat grid. These models, though less sustainable and trusted, have sufficed for most people and businesses, to date.

FinTechs and neo banks (e.g. stored value, deposit taking, payment services, lenders and many others), provide services that traditional financial institutions do less efficiently or do not do at all, and widen the pool of users of such services. But they will not replace banks as every FinTech is required to safekeep its users funds in a traditional bank (e.g. credit institution, or central bank). The inherited tension and ”cultural gap” between FinTech and banks is obvious, however, FinTechs are carrying the daily burdian to maintain these relationships as for them it is “cease and desist”; either you have a bank as a sponsor or partner, or you die.

Allowing FinTechs to actually manage their biggest risk driver in these relationships: the pay-ins and pay-outs from the aggregated customers account, presents a fundamental value proposition. Currently, the banks know the outcome of each wire transfer and its merits as soon as it is lending in or sent out from the aggregated account. FinTech find the outcome only after the data passes from the bank, if it passes[1]. Given this fact, many banks are reluctant to service FinTechs and many relationships are maintained on a thin line of trust between C-levels, as FinTechs force banks to act as the “first line of defence” while both sides don’t really collaborate and manage the risks. If these entities would have presented the ability to understand the merits behind each wire transfer before it hits the payment grids and accounts, they would likely benefit from a better ability to partner and relate, and mainly, reduce the daily fear of “de-risking”. FinTechs and banks will be able to  manage their transfer flow according to risk vs. reward matrix, and avoid the daily routine of nemours exceptions cases and mitigation tasks.

The challenges with this approach are:

  • Compliance hurdles – Some members in the FinTech segment are risk tolerant and prefer to deal with the risk of losing to mitigating their relationships rather than to take the role of “first line of defence”, which adds additional compliance liability and friction between front office and compliance.
  • “Front page” risk – Put simply, the risk of bad PR. If the parties will not understand the implications of actually understanding the merits of each wire transfer and manage the cases with consumers with transfers being rejected, there’s risk of backlash against these FinTechs, as well as their partners.
  • Consumer Data – FinTechs are in essence a distributors or affiliate of financial services. Their main focus is their customers, their CAC, UX/UI and LTV. As such, their basic approach is not sharing their customers’ data. Thus, the actual resistance may be lower than assumed, taking the benefits of this opportunity.
  • Change management – becoming the “first line of defence” is requiring a change. Payment Services would need to adjust their operational models and work with their units to take advantage and factor the additional liability and opportunities of this data access. For example, the ability to route transfer per risk to different banks. In addition, some Payment Services don’t currently hold multiple banking partners and can’t operate multiple routing. And in the case of a single banking partner, it will be necessary to either reject some transfers, or partner with multiple banking partners and set the preference order around the banking partners.

B2B Transactional Fintechs

Difficult-to-access wire transfer data is of particular value to those building business fintech applications. Historically, wire transfer data has been the sole “property” of banks and regulators, and integration to their API (if possible) is painful and time consuming, often taking months. This use case builds defensibility as well: the API provider needs to get IT and security approval (minimal SOC1 and SOC2) from the enterprise application team before use, particularly since it contains sensitive data.

The challenges with this approach are:

  • Approvals take time – The downside of needing IT and security approvals is that this process often takes time, and high costs.
  • Unknown TAM – While this data is valuable and was previously hard to access, for many enterprise applications its uses are unproven.
  • Consumer consent – While the simple wire transfer data itself is less sensitive — it’s already coming from and being used by the banks and Payment Services — other types of the wire transfer data (for example, the relationships between the Payer and Payee, or the history of the Payer with its bank) might be more sensitive requiring a standalone consent.

Trade Finance
Enabling banks and liquidity providers to seamlessly operate and execute trade finance transactions is incredibly valuable to B2B fintech companies, making it an interesting wedge. The company (for example a neo bank focusing on SEMs or business) that wins trade finance likely wins the business customer’s engagement and greatest share of large volumes wire transfers and spend.

The current trade finance process is slow and filled with friction similarity to the corresponding banking sphere, provided however, that in this case credit rating and collateral are playing a significant role. It takes undless manual cycles to implement a full transaction of trade finance from issuing the credit letter to releasing the wire transfer. This acute pain point creates an opportunity for software to automate the switching process.

The challenges with this approach are:

  • Smaller TAM – The existing market size for Trade Finance may be small and even smaller in the next years — even capturing a large number of those transactions at $5/Wire implies a smaller than usual market for a venture-backed startup. However, market sizing is inherently challenging for startups: most are attacking potential markets, not existing markets. In this case, one could imagine layering on Trade Finance of products like corresponding banking, which would increase LTV and market size significantly.
  • Competing models – Though more accurate and augmented data could improve Trade Finance services by the banks, many newcomers currently have models for how to overcome the basic problem and friction by using new blockchain technology. For example, We.Trade, offer a hyper ledger (DLT) based network to businesses for Trade Finance. These models, though less trusted, are the main success use cases for blockchain applications in the financial sphere.
  • Low defensibility – While Trade Finance is an interesting wedge, it isn’t particularly defensible given the lack of recurring use or network effects. A customer could easily move from one Trade Finance solution provider to another; the utility is one-off on a per-case basis.

While each approach has its trade-offs, we believe that the most successful Wire Secure API will have the following characteristics:

  • An urgent use case – Wide adoption of Wire Secure API will require a highly motivated customer, and the more complex the implementation (i.e. Liquidity) the higher the value will have to be. For Aggregated Accounts, for example, API solutions will need to differentiate through improved coverage, data types, and allow a pre-transaction view of the contect.
  • Recurring use cases – Switching transaction-liability data providers would have meant losing access to historical data and asking the customer (B2B) to re-authenticate. The winning product in this space will have some recurring use-case, which both provides a defensive moat against competitors and the potential for recurring revenue.
  • Expansion potential – Natural expansion path within an organization, selling to multiple buyers or having the same buyer purchase multiple products, say cross border transfers, trade financing and virtual accounts.. There is a clear path for this to happen within fintechs and correspondent banking, given that many of them are converging on a similar product strategy (deposits + FX + Wires). Whatever company is able to build early momentum in a single space will be well positioned to win in others.
B2B Transactional Fintechs Aggregate Accounts Trade Finance Correspondent banking
TAM 3 1 2 1
Urgency 2 2 3 2
Definsability 1 1 3 1
Ease of Rollout 1 3 2 3

The wild card: The Grid

Like, banks love-hate relationships with FinTEchs that use open banking to pull consumers data, same relationships are foreseen for wire transfer API.  That reticence is twofold:

  1. fear of issues around information security,
  2. as well as around losing direct control of the customer.

Wire transfer API would also need to gain trust and reliability of their data in order to become an integral part of the value chain. This process might require an informal approval from regulators and associations (for example the FATF) and close work with central banks and governing bodies.

The current scene however is mitigating the risk, as there’s a strong precedent for making consumer-permissioned data accessible to third parties, and willingness of payment tinfrustcutres and banks to open their “grid” to startups. Regulators are also advancing “Sandbox” projects demonstrating their willingness to support innovation.

[1] If the Payment Services is not connected by API to the segregated account, then the data is sent by a request

Scroll to Top