Connect your fintech

If you are facing months of boring integration development to connect your fintech to Currency Cloud, then this simple guide will help you fast track so you can get on with more exciting product development on the front end.

All you have to do is request one simple API from Integrated Finance which then takes care of your Currency Cloud connection. What’s more, it also keeps the connection up to date if Currency Cloud changes its API when live.

But the benefits don’t stop there. You can also quickly connect other vendors to the Integrated Finance Hub alongside Currency Cloud such as Railsbank.

Known as IF CONNECT there are no upfront development costs, just one monthly “pay as you grow” fee which also makes it the ideal solution for start-ups and those financing product development projects.

So, when we quickly connect you to Currency Cloud you get all the services you expect very quickly:

  • Access Wholesales FX Rates
  • Client Safeguarded Accounts
  • Local UK payment schemes
  • Local European payment schemes
  • SWIFT
  • and more…

For more guidance on connecting to Currency Cloud easily, request a simple and quick no obligation demo by getting in touch today. We love showing developers the simplicity of our solution.

Railsbank

If you are a financial service provider and want to make a new connection to Railsbank quickly, the new platform IF CONNECT can help easily automate your integration. What’s more, if you are using other vendors such as Barclays, ClearBank, or CurrencyCloud, you can also connect to them easily and use all the systems together, seamlessly.

This platform does the hard work for you, so you don’t need to, with one simple API for Railsbank and more. 

Connect once, and for all

When you Connect Railsbank to any one of the multiple finance systems it is compatible with, it will automate the process in one quick and easy way. By connecting Railsbank alongside other vendors and your front-end platform, you can then perform several actions that you’d expect including:

  • Accessing Wholesales Foreign Exchange Rates
  • Issuing bank accounts to your customers
  • Multi-Jurisdictional Licence
  • Compliance-as-a-Service

The best way to connect Railsbank with Fintech

IF CONNECT only needs to be connected once, and it will keep all your systems up-to-date even if banks change their API. By effortlessly introducing new payment providers to your platform, for example integrating Barclays Bank, CurrencyCloud or Clear Bank, or any other FinTech, it turns it into the ultimate SAAS banking solution for you and your customers.

In fact, you avoid high upfront development fees and then pay as you grow on a monthly basis.

How to connect to Railsbank easily along with multiple vendors

All the systems are connected seamlessly to one hub (IF CONNECT), easily connecting several banks, apps and financial compliance tools including AML, KYC or KYB.

The application also keeps the connection to Railsbank and other systems up to date, even if the bank changes their API (which happens frequently).

Fast track fintech product development

Using IF CONNECT as the hub, you can also easily grow your product offering by quickly introducing new payment providers that match your specific needs. You can add Barclays Bank very easily for example.

We take the hard development work out of making the connection to Railsbank and others, so you can focus on your own product development.

What’s more, if you also need a modern front office customer portal, IF CORE may be the ideal SAAS banking platform for you – with connections built in.

Request a demo by getting in touch today.

Fintech infrastructure

Modern customer-facing financial services are all built on a stack of third-party vendors. That stack typically looks something like the below, featuring market infrastructure, bank transactions, card transactions and data access:

The driving force behind the modern financial service stack is the unbundling of banking services, with each product and service on a level of the stack now delivered by a single firm. This compares historically to a single firm delivering services on every level of the stack directly to the customers.

The benefits businesses get from unbundled banking include: better products at much more visible prices and availability to a wider audience, particularly at the lower end of business size where high fixed costs are more of a blocker to get started.

The downside to the new stack is the need to build and maintain multiple financial integrations on each level depending on what service a firm provides to customers. That comes with upfront development costs, as well as the opportunity cost of not having developers focus 100% on the core offering.

Out of the new financial stack three business models have emerged to help businesses building financial services products:

  1. Unregulated BaaS Providers: these Fintech’s offer banking infrastructure APIs to customers and partner with a few banks or Fintech’s (usually 1-4) on the back end. Examples include Bankable, Marqeta & Swan
  2. Regulated Banks and Fintech’s Offering BaaS APIs: this includes both legacy (e.g., Citi, Goldman), digital-first banks (e.g., Clearbank, Cross River) and larger Fintech (Railsbank, Currency Cloud, Nium) offering APIs through BaaS platforms.
  3. Unregulated API Routing Layers Offering Financial Infrastructure API Marketplaces. (e.g Integrated Finance, Bond). A financial service routing layer offers access to a large ecosystem of banks and Fintechs (all of the providers in 1 & 2 above), giving customers much more choice over who to partner with and vastly reduce the risk associated with dependency on a single provider, should they go down.

We may be biased, but we think the third model (API routing layers) gives some major advantages to businesses building financial service products in the modern world.

Integrated Finance is an API routing layer for financial services. Our platform enables you to programmatically access multiple financial service vendors via a single API, removing costly upfront integrations and significantly reducing the often hidden ongoing costs of maintaining those integrations.

Get in touch to find out more.

API routing layer -Advantages of using an API routing layer

Modern customer-facing financial services are all built on a stack of third-party vendors, with three core business models emerging – unregulated BaaS providers, regulated banks and fintechs offering BaaS APIs or unregulated API routing layers.

We might be biased, but with the help of Integrated Finance, we think the API first, developer friendly routing layer model gives some major advantages to businesses building financial service products and here’s why.

Building and maintaining multiple providers

As the new financial services technical stack emerged so too has a plethora of suppliers that focus on each specific layer. With many fintech vendors looking very much like enterprise sales organisations,  identifying subtle differences in services providers can be hard for customers without specific background knowledge. Time then is wasted on selecting the wrong vendor, getting a commercial agreement and integrating. The huge opportunity cost for a business is not working on your core offering.

Beyond the distraction of building your core I.P another distinct challenge is that whilst each supplier does more or less the same thing, the way you interact with these vendors varies greatly. The data required to post and receive information for account generation, FX, and regionally specific payments has no unified standard. There is no open banking API for this stuff.

Simplifying difficult to do, legacy financial integrations

Anyone who has tried to connect to a bank running on legacy systems will know what a pain it can be, both from the customer and bank’s perspective. For customers, legacy connection methods are difficult to implement without specialist help because of sparse information in the large code repositories.

Banks and legacy bank integration firms have been slow to externalise their knowledge, making it harder for developers from outside financial services to find useful help without paying and third parties to do the integration on your behalf. 

Integrated Finance builds and maintains difficult, legacy integrations and transforms them into a simple to use modern API. Crucially, banks will continue to play an integral role in our ecosystem, providing a modern wrap-around for their own legacy integration methods.

Focus on your core offering, unleash your developers

Let’s face it, financial service integrations are not cool. They are also probably not your core customer offering. During the initial stages of getting a product working, integrations might seem important but as a business scales they soon lose their allure.

It’s a problem we see again and again, choosing whether the team’s responsibility is to look after non-core integrations, when there are super cool (and urgent) core customer features to build. So it gets neglected and responsibility falls through the cracks. Then disaster strikes, one of the vendors changes their APIs and your whole system goes down and the CEO shouts at you.

API routing layers solve this problem, allowing your development team to focus on your core offering and not needing to worry about maintaining uncool financial plumbing. Our platform attaches a SAAS fee to the unsexy task of building and maintaining integrations to your financial service providers. Overall organisational cost is lower than having your developers distracted and focusing on non-core features.

Advantages for product teams

Using a routing layer gives a product team access the functionality of a company with significantly larger resources. Built in redundancy where you can easily route traffic to multiple providers or add and subtract vendors quickly and easily. The API routing layers enable fast growing products to quickly achieve the right cost, speed, reliability, or experience optimisation for your business.

Leveling the playing field. Turning high fixed cost financial infrastructure into a pay-as-you-grow subscription

Financial service companies of every size can now, either early in their development or as they scale, add massive optionality and coverage to their product offering via our API routing layer. Our customers are able to enable similar impact and feature depth as much larger and better funded competitors at scale.

Get in touch to find out more about Integrated Finance.

connect your internal systems -Free Connectivity in Fintech White Paper

There are many things you need to consider before you start building a transactional banking fintech service. For example, do you know how to keep integrations up to date? Have you thought about how to safeguard your clients’ money as well as your own? Did you know there were FX cut-off times?   

In our latest free white paper download, titled ‘How to Build a Transactional Banking Fintech Service’, we look at the various points you need to know before you start. 

Download now to learn more.

Free Transactional Banking Fintech Service White Paper 

This white paper is a guide and glossary containing the things you need to know in order to build and maintain a transactional banking fintech service.  

We have listed the terms, products and processes you need to be familiar with and explained them clearly in individual, bite-sized sections, because it is so important to know your stuff. 

Download our Transactional Banking Fintech Service White Paper now to learn more.  

Download

Free White Paper on Fintech Connectivity



Making financial infrastructure connections? We can help! 

If financial infrastructure is your thing, Integrated Finance can help. We build, implement, and maintain disparate financial integrations, so that your developers can get on with building the products and solutions that delight your customers. 

Let us help you save time, and implement a new, simplified way of doing things in fintech. 

Get in touch to discuss how we can help.

There are several different types of integrations that financial service providers use to allow you to connect your internal systems to theirs. And there are many ways that you can use these connections to automate your messaging, instructions and reporting. However, there has been a recent explosion of APIs in Fintech.

So, what is an API? And can they really transform financial services for the better?

We explore this and much more in our latest White Paper. Download now.

Download

Free White Paper on Fintech Connectivity



Or read on to learn more.

APIs – The Basics

An Application Programming Interface (API) is a computing interface which defines interactions between multiple software intermediaries. It defines the kind of calls or requests that can be made, how to make them, the data formats that should be used and the conventions to follow.

APIs are flexible. They can be entirely custom, specific to a component, or can be designed based on an industry-standard to ensure interoperability.  

How APIs are used in finance

Most financial services APIs are currently custom architected, but industry standardisation is underway driven by not-for-profit collectives such as the Banking Industry Architecture Network (BIAN) or the regulators in relevant jurisdictions (PSD2 being an example of a more mature one). 

APIs are transforming financial services for the better, but progress has only just begun and that’s why you’ll often hear the phrase “Fintech is only 1% finished”. But it’s possible that APIs will end up eating financial services as we know them today, allowing for a revolution in both what we consume, and how we consume it.

APIs and the Xaas

APIs have also helped to spring up their own industry discipline type, the XaaS (As a Service). Particularly, Banking-as-a-service, where firms build a technology layer over traditional financial service products and expose the functionality in a more intuitive and accessible fashion.

This XaaS connective layer is transforming the industry from hard to connect and stand-alone services into public APIs. They are easy to talk to and open up a whole new world of possibility in terms of real-time interactions with financial service providers.

Specialist service providers emerge

The traditional financial services stack, usually soldered together within a large bank, has been unbundled into separate products with one or a few specialist firm/s hyper-focussing, on amplifying the specific product or service. Customers can access these firms via customer portal or app and via each firm’s own public APIs.

What the addition of public APIs is allowing these specialists to achieve is their own version of the sellotaping together of products and services and to create a mashup of a banking stack. The difference now is that you can pick the best in class provider of each service to combine, and those providers are generally open for any business to consume from start-up to enterprise.

What are Open Banking APIs?

Open Banking APIs were mandated by the European parliament to ‘promote the development and use of innovative online and mobile payments’. PSD2 requires all banks and PSPs to offer ‘open’ APIs. The open in this case means access by third parties to certain information the bank holds about an account holder (for example spending history) and to perform certain things on the account holder’s behalf such as initiating payments.

Open Banking APIs currently have limited use cases. If you imagine the financial services stack as an iceberg, Open Banking is the bit bobbing above the surface. Navigating the complex sea of financial services requires a much deeper understanding of technologies old and new. To offer the full tide of banking solutions, one must embrace a whole host of disparate and custom APIs (and other connection methods) that exist underneath the waterline. It is these integrations that will allow access to the heavy lifting financial operations that may go on to create greater industry innovation.

Other types of connections

APIs are not the only option. There remains three other popular and incumbent ways to connect to financial service providers.

To find out more about these, and explore which approach could work best for you, download our free White Paper: Connectivity in Fintech

Need simpler Fintech integrations?

Integrated Finance helps build, expand and manage financial infrastructures, quickly, easily and at a low cost. The company launched in October 2020 with the introduction of both IF CONNECT and IF CORE, the first time that any business has focused on simplifying the integration process in the Fintech market.

Get in touch to discuss how we can help.

white-paper-download

If you’re in Fintech, you’ll no doubt have heard a lot about Virtual Accounts in recent years. But, do you really know what they are and what they are for?

How about why they are so popular?

And do you know how you can build them? And whether it will be a worthwhile investment for the future?

We’ve had so many discussions around these questions (and more!), that we have put together a Fintech White Paper compiling our thoughts, and its available to download now for free.

Free Fintech White Paper on Virtual Accounts

The White Paper is written by Daniel Cronin, co-founder of Integrated Finance, who previously ran an E-money firm in London and has extensive experience in the Fintech sector.

It looks at their origins, their use, their context in the modern Fintech landscape and thoughts on their future.

It covers all the most frequently asked questions about Virtual Accounts, such as:

  • What are Virtual Accounts?
  • What do Virtual Accounts do?
  • Why are they here?
  • Who are they for?
  • What’s virtual about them?
  • What is the difference between virtual and bank accounts?
  • Why does Fintech love Virtual Accounts?
  • Why do so few banks offer Virtual Accounts?
  • Does it matter what tech I use if I want to build them?
  • Where and how can I get them?
  • What do banks and regulators think about Virtual Accounts?
  • What does the future hold for them?
  • And more….

Even within the finance sector, few are aware of the wide range of uses for Virtual Accounts and many assume that they are unnecessary in banking, with niche value. However, we believe they have a very important role to play and offer significant benefits.

Download the Virtual Accounts white paper now to learn more.

Download Now

Fintech White Paper on Virtual Accounts



An easy, integrated approach to financial infrastructures

Integrated Finance helps build, expand and manage financial infrastructures, quickly, easily and at a low cost. The company launched in October 2020 with the introduction of both IF CONNECT and IF CORE, the first time that any business has focused on simplifying the integration process in the Fintech market.

Get in touch to discuss how we can help.

One of Fintech’s more in-vogue products of the last five years is Virtual Accounts. Virtual Accounts go by a lot of different terms, vIBANS, virtual ledgers, named accounts, sub-accounts, ZBAs and quite a few more.

But why are they needed? And what do you need to know about them?

Read on or download our latest White Paper to find out.

Why are Virtual Accounts needed?

Like most inventions, virtual accounts were built with a specific use in mind. The use case being to help businesses reduce errors in payments and referencing, and the pain caused by said errors! Virtual accounts were designed to give businesses some simple benefits. Namely:

  • To reduce (or rationalise if you are a treasurer) the number of bank accounts you had to maintain
  • To simplify cash management and reconciliation
  • And to provide the same level of control and reporting as traditional accounts

Problems with Virtual Accounts

Let me give you a real-life example of only one of the numerous times it has happened to a business.

The following happened to a previous venture of one of our co-founders. The company was growing quickly and in need of some office supplies. Most staff preferred to use Mac instead of Microsoft, so an order was placed for around 10 MacBooks.

As a Fintech player, the company tended to maintain a lot of balances with partner Fintechs. CurrencyCloud was one such partner, and for operational convenience, settled its outstanding bill with Apple through a CurrencyCloud account. The payment instructions were entered, and the Apple corporate account reference number was (correctly) applied, and off the payment went. 

CurrencyCloud generated a proof of payment document later that day just for certainty and that should have been the end of it. However, a few weeks later an email was received from Apple.

“Funds not received, please pay asap”

Our co-founder called them up and explained the funds had absolutely been sent, told them the date and the amount to the penny.

“We do not have a record of that on our system”

The proof of payment and the MT103 was emailed to them.

“We do not have a record of that on our system”

He assured them that payment has been sent and requested to speak to a manager. After about a week he spoke to a manager and went through the same process, explaining that a payment had been made on X date for X amount and with XXX reference. Could you please check for those details only? Their response….

“Why?”

“Because I think you are simply looking at our corporate account record rather than checking your bank statement.”

“We don’t have access to our bank statement, we are the customer service team”

On and on this went until eventually our co-founder realised that Apple, being Apple, probably have a corporate account for 75% of the entire UK corporate market. So, it was time for a change of tack.

“I know you can’t talk to me about other customers, but if you could please check your system to see if you have a customer called CurrencyCloud and if you do I am confident you will find that you have received a payment on X date for X amount and with XXX reference. Moreover, that will not be their corporate reference, it will be ours”

“I cannot comment on other customer information, but I will revert and get back to you.”

“CurrencyCloud”, he continued, “are a Payment Service Provider, and the very nature of their business is that they send payments on behalf of other companies. Doubtless they will have an account with Apple too and what has likely happened is the accounts receivable team saw the sender name as CurrencyCloud, never bothered to check the reference and simply applied it to their account.”

In a week an Apple Manager called back. It went like this:

“I can neither confirm nor deny that we received a payment from CurrencyCloud but if you do have a relationship with them, please get them to write on letter headed paper a message to confirm you are their client and that payment of X on X with XXX reference was intentional and meant for X company.”

After another week this was resolved and finally the credit was applied to the account (doubtless causing CurrencyCloud some of their own reconciliation issues later).

The process took six weeks from beginning to end to resolve. On man-hours alone, it probably cost both the company and Apple the same amount as the initial purchase to resolve. Going through layers of management and approvals and pulling in three businesses distracting them from their core activities.

And all the above because of a single error caused by a manual process that relied entirely on an arbitrary reference.

The Benefits of Virtual Accounts

Now just imagine if Apple had the technology (which doubtless they could implement) to give every single customer their own unique virtual account number. In most countries the standard digit count for an account number is 8 meaning apple could offer 100,000,000 million unique account numbers (per routing/sort code).

This would enable a system where each Apple customer no longer uses a superficial reference number when making a payment, instead they simply pay (in the same normal way) to the account number presented on the invoice.

This removes any possibility for a misallocation of funds. This removes any uncertainty around purpose of payment or identity of sender. It removes the need for manual intervention and fund tracing. For Apple, it empowers them to know if a customer has paid, simply by checking whether the virtual account they have for the customer in question has had any funds pass through it. And this is a very important detail.

Virtual Accounts allow funds to pass through them. They are conduits for fund transmission. It wouldn’t be very helpful if Apple had to go and check millions of virtual accounts every day, and then transfer the funds to a central operational account. The benefits of reconciliation would be dwarfed by the cost of operation. But to be able to have millions of payments everyday collected in separate unique virtual accounts and to have those payments automatically land in a house account – now that is powerful.

With this kind of technology, Apple (or anyone for that matter) could dramatically reduce the cost of running an AR team. It could also drastically improve customer service and user experience, cutting down on invoice cycles and disputes. It would, at a stroke, remove 90% of the manual errors that create the need for heavily resourced and non-revenue generating bureaucratic environments.

Had virtual accounts been deployed, the issue described above would never have happened. It wouldn’t matter what reference was put on. It wouldn’t have mattered that CurrencyCloud made the payment on our behalf. All that would have mattered was the amount of money and the virtual account number that was on the invoice.

As powerful a solution as the above is – that’s not what’s driving their adoption in Fintech. There is something much less marginal at play.

To find out what, download our free White Paper: Virtual Accounts – A Fintech Love Affair.

Need simpler Fintech integrations?

Integrated Finance helps build, expand and manage financial infrastructures, quickly, easily and at a low cost. The company launched in October 2020 with the introduction of both IF CONNECT and IF CORE, the first time that any business has focused on simplifying the integration process in the Fintech market.

Get in touch to discuss how we can help.

From as far back as the ’50s, when consumer payment cards were first conceived as an alternative to hard currency, there’s been a relentless march towards spending on plastic. Whilst initial adoption wasn’t exactly revolutionary (card spend during the ‘70s was under 15% of all transactions in the US), the tide of consumer mentality slowly began to turn. Driven by consumerism and international travel, by the ‘80s it was clear plastic well on its way to becoming the new norm. The trend accelerated through the ‘90s, and ’00s, powered by the development of the internet. By the turn of the century projecting the trend forward the media were actively talking about the impending death of cash.

I for one stopped bringing out my ‘just in case’ cash by 2005 and solely relied on card. By 2010 cashless was overwhelmingly the preferred method of consumer purchase. Innovation occurred only superficially with prepaid cards and virtual cards increasing in popularity. And this bonanza of polymer payments created Titans of the money transmission world. To be in the middle of it all, pulling the strings behind the scenes, controlling multinational grade value exchange every day, was the place to be. The epicentre of payments was occupied by two titans of payments – Visa and Mastercard.

Visa and Mastercard’s, dominance and ubiquity in the payment space is a modern marvel. For over 60 years their presence and influence has gone from strength to strength, steadily gobbling up market share as they expanded.

But if history teaches us anything, it’s that nothing is permanent. Empires rise and fall; success is never guaranteed. Adapt or die. It’s as true for biological lifeforms as it is for ethereal corporate entities. The relentless march of technology is now enabling the development of competing payment technologies, not only potentially faster and significantly cheaper but for the first time in 60 years, viable alternatives to card.

When we look at the evolution of the payments industry in the next 10 years, the question arises: will open banking or other potential alternatives to card herald the beginning of the end for the incumbent schemes? Or is a trusted third party at the centre of a payment scheme a requirement for it to flourish.

Development of Open Banking standards is creating a brand new set payment rails and creating a mini gold rush in the world of payments. We are already seeing the first new trains in the likes of Plaid and Truelayer. Though who will be the boxcars I don’t yet know.

The first passengers onboard as always will be the individuals. But not far behind, waiting their turn quietly, is the Retail Industry or what I tend to think of as the Adoption Mafia. Very little in payments succeeds, if these guys don’t like it. For years these guys have really only had Visa or Mastercard to choose from. Any business that begrudgingly slaps a Visa or Mastercard acceptance sign on the shop window (or increasingly on the website footer) has long been looking for a new way of accepting payments without compromising conversion.

With high hopes and bated breath then, the world of retail waits to see where these new tracks will lead.

The use cases of open banking are plenty, if not always so well-illustrated to the public. Why, for example, wouldn’t I want to pay for goods in the same way that I pay my friends.

The one who always (earnestly) promises to pay me back next week (but somehow never does). Or the guy who got me lunch when I left my wallet (phone) in the office. It’s quick, it’s easy and the aforementioned friend gets the funds practically instantly.

Let me set another scene for you to demonstrate my (or in reality the Merchant’s) case.

Most Friday nights I order the “Joey Special: (that’s a Friends reference for those of you who got it) From a popular Pizza Chain. I won’t mention the name, although as I’m a sucker for quizzes I will give you a clue. It rhymes with Tominos.

Anyway, where was I. Oh yes… I’m ordering my Friday Night Takeaway, I reach the checkout page and I’m met with a plethora of payment options ranging from Applepay to Visa Direct, cash and of course the traditional and ever-present card. Over 80% of us today choose some version of a card transaction. Deal done! All good so far. But what follows is where things can become (from the retailers perspective), a little less savoury.

So, deal done. Thanks Visa/Mastercard! What does Tominos do now? Well, presumably they will start creating the product immediately. They will, knead, stretch, baste, top and bake that thing – often within 10 minutes. Then box, stack, pack and deliver it in another 10. A marvel of modern efficiency you might say. Everyone’s happy, right? Well, no, not always.

This is where the train sometimes derails.

A day or three later the pizza restaurant will receive my hard-earned money, minus a pretty penny (or a few hundred) for the pleasure of accepting the transaction. In that time lag, they live in a pretty powerless black hole.

Why? Well, it’s simple consumer protection. Let’s take a look. The consumer may have not been happy with the product. The consumer may have gotten ill the next day and decided (rightly or wrongly) to blame it on the pizza. The consumer may have had their card or details stolen, and in actual fact, it wasn’t them who ate the deliciousness. Maybe the customer didn’t calculate their monthly budget properly and just simply had to make an emergency halt on the transaction.

Whatever it was, Tominos have to sit still and cross their fingers simply praying that none of the above happen. Because if it does, they have just done all that work for free. Worse, they’ve actually lost money. Ignoring the obvious overheads of running a business just processing the payment has a cost itself. Not to mention the fact disputing or accepting the refund request can be the most expensive part of the process. Try punching those into your Unit Economics model!

Consider (again for the merchant’s sake) the same experience but with the payment via an open banking solution. Instead of choosing to pay by card, I decide to “Pay by (insert business brand that succeeds in the OpenBanking race) Bank Transfer”. With the click of a button, your bank app opens, you verify it with your thumb or face, tick approve on the payment and then arrive back in your Tominos app. Well, the benefit for the customer is broadly the same as if paying by card, simple and convenient. But the benefit for the merchant is significant, no card scheme fees to pay and more importantly no chargebacks to worry about. Bank transfers are final.

Whilst it might seem odd to do a bank transfer for a pizza, soon it will become the norm. Think about it, how do you pay back the friend that managed to get Glastonbury tickets for you, or lend your sister £50. Most likely if you’re in the UK – you do a bank transfer. Why then would it be unusual to pay for your pizza, or an Amazon order, or any myriad of things you’d use your card for on a weekly basis. The answer is quite a simple one – convenience. And if there is one thing every purveyor of any goods (ever) covets above all else, it’s keeping things convenient.

Whether it’s a thronging Bazaar in Ancient Mesopotamia, a dusty and stiflingly hot Mercado in the Aztec city of Tenochtitlan, the posh Farmer’s market at the nearby Hackney, or from the comfort of your own home on the Amazon.com omnimarket, once the buyer has signalled an intent to buy then convenience is king. If you lose that sale because of convenience, then all the rest of your hard work has been for nought. In capitalism, there are few more bitter pills to swallow.

Visa and Mastercard, as trusted third parties in the card space and providers of the ultimate financial plumbing, allow companies to focus on making it convenient to spend on a card.

For OpenBanking, the same global intermediary does not exist……yet.

There then is the paradox for the Merchant. As bad as the burn of card scheme flaws can be, the burns are in most cases superficial leaving at worst a scar. On the contrary, the scar is also a mark of success. You can’t get the scar if you didn’t make the sale in the first place. 

There can be no fraud, no refund or chargeback for the sale that never was. So for all its failings, only a fool would reject something that actually enables the sale.

OpenBanking provides both threat and opportunity to Visa and Mastercard, pioneers and oligarchs of the payments industry. A viable new payment technology is on the horizon.

Adoption might not be as rapid as its most ardent proponents hope, but it is coming. At its core, it’s a fantastic alternative to Visa and MC’s more established payment methods, but currently has flaws that inhibit its mass adoption. And this leaves the Duopoly a tough but ultimately simple decision to make.

To Buy or to Die?

To pursue continued improvement in card technology now seems a game of diminishing returns. A card, at its most basic, is an identification card allowing access to your bank account. It tells the recipient of funds who the customer is, that they are allowed to take money from this customer and from where they may take it. It tells the steward of the funds (the bank) that the customer has permitted this transaction and that they may release the funds.

This technology has all now been digitised, all internalised. The banks already have the technology to release funds to any account in the world. They now have the ability in real-time to authenticate users and permit one time and multi-time third party access. In short, they are able to insource all of the technology that they have previously outsourced to the schemes.

Why then would Visa and Mastercard continue in parallel doing the same thing? Technology it appears, has caught up with them.

You can see from the acquisition patterns of the last few years that Visa and Mastercard themselves identified it. 5 Billion+ for a Visa partnership with Plaid to gain access to account data, payment initiation and user bank account insights. 

The acquisition of the global bank transfer network Earthport (from right under Mastercard’s nose) highlights this push into the bank transfer space.

Mastercard haven’t been idle either. Their purchase of Scandinavian payment juggernaut NETS’ Account to Account payment system and Otlio, the South African digital payments and authentication solution shows they are equally interested in the digital bank transfer space.

It’s clear and obvious then that the intention is to Buy. And with balance sheets that most organisations would …die for… it makes sense to open the cheque book.

Earlier I mentioned OpenBanking has some drawbacks. The drawbacks have never been about the technology though. The technology has been sound for years – it’s ultimately a bank transfer.

The problem has always been threefold:

1. Security.

2. Bank Reticence.

3. Convenience.

Security because the Banks’ principal responsibility is to not lose it’s customers’ money. if they can’t assure us of that then it’s back to the days of cash under the mattress. But whilst security will never be 100% assured, it never has. Security has always been a game of percentages. Take chargeback ratios of schemes. Visa and Mastercard don’t say to the tenants of their respective schemes, “you cannot allow fraud or have any chargebacks”. Rather they instruct the stewards of their schemes to aim towards “acceptable” levels of fraud/chargebacks on a monthly basis – say below 1%. Banks similarly adopt a percentage approach where they aim to keep wire fraud to a minimum. Both methods ultimately have to accept that eliminating the risk entirely is not feasible. To that end, the increased regulatory focus of wire fraud in the last 10 years has helped to create an infrastructure in parallel to the card schemes that offers equivalent security for third party bank transfer access. This, in turn, has decreased security risks and in turn removed much of the prevailing bank reticence for engaging with the OpenBanking vanguard.

Bank Reticence because well, nobody likes change. From the banks’ perspectives, this is a whole load of cost and risk, for essentially very little upside. The less they control the movement of customer funds the less security they can offer. (And not to mention the less money they make). As we discussed above, the leaps forward in technology has dramatically lowered the exposure (and accountability) to the risk of TPP and therefore kicks out from under the banks a leg of resistance. The other leg (of resistance) – commercial protectionism – has been hopping along for much longer though. The Banks have every right to ensure they look after themselves. After all, nobody wants a bank to prioritise connectivity and access overcapacity to be a solvent entity. However as the market hype builds around OpenBanking, Banks have begun to see this as an opportunity to create a little bit of a PR spin. By aligning themselves with the leaders in the space, they are undoubtedly looking to attract the businesses of the future. Digital native 20 somethings will have no need for branches or probably even online portals. The business leaders of the future want it on their phone and wherever whenever. The fact that banks are now aligning themselves with Fintechs in the OpenBanking space just underlines how important it’s become to banks to be seen to embrace this new change.

Convenience is the final of the three obstacles. Right now OpenBanking as a checkout alternative requires the user to authorise a transaction (just like every other push-payment method) on each occasion that you transact. This makes sense as it allows the vendor and the buyer to validate each transaction in real-time. The problem however is that the Merchant as mentioned above – values convenience above all else. A bird in the bush after all – is worth nothing.

And whilst the incumbents of schemes might have their drawbacks, they ultimately result in sales conversions. One of the key reasons for this is that they allow the merchant to control the checkout experience. Moreover, they allow the experience to happen within the walls (or pixels) of the Merchant’s own domain. Tominos does not want its customers running to the ATM and passing a fish and chip shop just to get money out for the pizza. Equally, they don’t want customers logging into another app just as they enter the checkout. It’s a conversion killer.

OpenBanking as it presently stands would push the user outside of the app and force them to log into a secondary app for approval before a final return to the original app checkout page for confirmation. There is no upside convenience or conversion here. The very best case scenario here would be a 0% drop in conversion rate. And that ladies and gentlemen is about the least attractive sales pitch a technology can have.

These reasons are still serious barriers to entry and hurdles for adoption for OpenBanking. And all of which are exactly what VISA and Mastercard were founded for in the first place. The fact that technology has moved on doesn’t change the core of human desire. We want, fast, secure and convenient solutions. And Visa/MC can still have a place in this new world as an arbiter and participator in this new technology.

They are an existing trusted third party, helping secure and moderate the users. They have great relationships with the banks already and they can know how to build a payment scheme that is convenient.

OpenBanking is a fantastic initiative that will open up new, lower cost, lower fraud, hyper-efficient transaction initiation and transaction recording. But it’s still in its infancy as an applied technology. It still hasn’t been battle-hardened from the millions of users and decades of evolution the schemes have survived through. 

Visa and Mastercard are right to be cautious, but not to be worried. They should see a huge opportunity to expand their reach. They have the bank balances to sit back, open a bag of popcorn, and watch patiently to see which contestant wins this Payment Royal Rumble. And likely as not, the winner of the Battle Royale will become the latest in a long line of acquisitions in the omnipresent Duopoly. And, I’d argue, only then will open banking be in a position to rival cards for convenience.

And until then – like almost everyone else, I’ll continue to use ApplePay.

Four years ago, we had the opportunity to build our very first company. It went well (the business is still trading!). We made loads of mistakes, but learnt more in those four years than in the previous twenty. To sum the experience up in one sentence is difficult, but would be something along the lines of ‘a tough lesson in resource management’.

Our company was a digital banking, virtual IBAN and deliverable FX platform targeting the UK and European SME and e-commerce space. As founders we envisioned a global localisation solution, allowing businesses all over the world to trade as if they had a local presence in any jurisdiction they desired. As much as we tried, we never did come up with a good catchy phrase that accurately described our vision. We tried “Glocalisation”  but could never get past the fact it just looked like a damn typo! Armed with hyper-entrepreneurial investor, a smattering of developers and some borrowed resource, off we went.

In 6 months we got our (not quite) MVP out the door. Delighted with our work, we began to plan how to get the product ready to go live when our investor decided he was tired of waiting. Whilst we were nervous to launch without a fully fledged product, it ended up being a fantastic baptism of fire. Theorising endlessly over what the customer wants is never as good as the real life customer shouting “this is what I want!” Attracting our first customers and creating revenue was a fantastic milestone for us and with the full support of our investor, we began to hire and build out a more substantial development team. Perhaps foolishly we thought if we can build X with n developers then as we add more to the team, output would follow in a linear relationship.

We were very wrong in two main areas. The first problem is what I call the ‘efficiency lag’. This, much like a gear change in a car, is where momentum and speed temporarily suffers as the cars slows during the gear shift. The only difference is in a car the lag is momentary and the ROI almost instant. Not so in business!

We knew it would take a bit of time to hire. What we didn’t factor in was the immediate and long lasting hit it would deliver to our existing deployment timelines. As non-technical founders, our tech resource was also our internal hiring resource. We had no way to assess skillset, experience technical fit. We couldn’t induct or train. And we certainly couldn’t bring them up to speed on the specific methodologies of our technical development. That meant our most experienced (and thus most valuable) tech assets’ output capacity became unavoidably impaired. By the time the new hires were up to speed, we were already forced into major revisions of our deployment timelines.

In total, the efficiency lag increased cost and degraded delivery speed by a total of 5 months. Only then did the original delivery rate resume. It took a further 4 months before our delivery speeds overtook our initial timelines. Therefore we were left in the difficult position of having to explain to investors why the requested cash injection –  after three quarterly reports – had not impacted this year’s deliverables. An important lesson in forecasting and investor management was learned here, namely that more money does not always equal more speed.

The second challenge we faced is a more familiar concept. The concept of diminishing returns. As we began to position the business for scale, we realised the platform had become quite the beast. Having conducted a full tech and cost audit, we had realised that over 30% of our technology budget was being expended on pure maintenance. Every time we deployed a new product or migrated to a new provider, every time we implemented a forced regulatory alteration, or simply swept unforeseen bugs, there was a cost to it and a drain on our resource.

As we dug deeper, we realised a further 15% of our resource was simply handling integration maintenance. Every time a bank released a new feature, or upgraded their software; when a customer wanted to release a new feature that required minor adjustments, we were devoting time and energy to something that offered little to no value to our clients. Imperceptibly, over time we had become janitors of our own technology.

If our business was a New York apartment block, then we had become it’s ‘Super’. Our client’s didn’t care that their FX provider had implemented minor code alteration which resulted in Aussie Dollar wire delays. They didn’t care that how we screen payments in real time. They maybe didn’t even care that WE DID screen payments. Or that we were PSD2 compliant. Ultimately, the customer cared only about the ease and speed of the solution and the range of functionality. 

We assessed our monthly spend, spend to date, our  delivered product range and our conclusions were surprising to say the least. A total of 85% of our product spend was invisible to our customers. Worse, there were good features, necessary features, but they weren’t differentiators. Most customers don’t choose providers for their screening and sanction efficiency. They don’t choose one provider over another because of security environments, ledger maintenance or, audit records or web hosting scalability. They aren’t interested in internal liquidity management systems, or back office task automation. They want cool and unique interfaces, intuitive design, great client facing features. And we realised that we had compromised on what matters to customers because we COULDN’T compromise on what matters to regulators.

We realised that our business model, whilst executed well by us and many competitors, had at it’s very core a conflict of interest. And this (entirely necessary) conflict meant that without the mega-funding only available to a select few, we would never be able to focus all our energy on creating a product that – in its entirety – was devoted to the customer.

The financial services technology stack needs a rethink. We think the path forward is towards architecture aggregation.

In the 90s it happened with data. Cap/OpEx intensive server space prevented most innovation from flourishing in the space. Rackspace were early movers and transformed the market. Sowing seeds for smaller businesses to spin up innovative solutions without the capital burden of server maintenance. From there AWS ploughed the landscape far and wide, creating from a barren excess of capital waste, a fertile land for entrepreneurs the world over to create compelling solutions that could at once be deployed internationally.

Firebase took it even further for mobile development by providing a unified platform with built-in authentication, analytics, testing infrastructure, app messaging, monitoring, and much more.

Cloud platforms have ushered in a new era of innovation. The hallmark of their success has been the coining of a new term – the Unicorn – The Billion Dollar Startup. 

By focusing on solving the problem of heavy lifting on commoditised products i.e. those that don’t differentiate you, AWS, GCP etc have enabled new entrants to grow exponentially by focusing resource on things that make a difference. But Fintech for everyone but a precious few has maintained an element of imperviousness to this trend.

Say goodbye to integration hell

You’ve had a great idea, raised some funds from investors and are trying to launch a financial technology company. You now need to find different vendors and cobble a solution together. After negotiating with at least three FX providers, 2 IBAN vendors, a few data aggregators and a KYC specialist you realise there is overlap across almost all solutions. You’re left with two choices, Firstly, build it yourself. I hope we’ve shown this is increasingly becoming a thing of the past. Secondly, go blindly with one provider and pin your success to them. Worst idea ever! Rule number one of financial services is make sure you have built in redundancy.

Yodlee or Plaid. Currency Cloud, Ebury or Banking circle. All excellent companies but with significant service overlap. You now have the complex challenge of combining these systems into a cohesive user experience. And the ever present challenge of maintaining connections to them all in the background. 

After 6 months of the year researching and negotiating with vendors, the development team can finally start to build the integrations. Great engineers are hard to find and most of the best lack the domain expertise or operational experience needed to build a FinTech platform. Teams are stuck in workflow hell of trying to build an operational platform to monitor transactions, provide visibility for auditing and answering questions (customers tend to ask questions when they’re confused about what’s happening with their money), and tools for handling exception and reconciling data from disparate data sources.

After six months, the product is far behind schedule, the costs are ballooning, the development team is frustrated, and very little work has gone into building the company’s core IP.

This is exactly what happened to us and we know we are not alone in experiencing this pain.

Focus on your core product

Few business models and pitch decks tout the significance of smooth integrations and secure environments. It’s not what compels investors and customers. Competitor fintechs don’t succeed because they had a great money transfer mechanism. In the same way DevOps services like replication, encryption at rest, auto-scaling/auto-healing, are now commoditised, FinTech services like FX, money transfer, account verification, user-level auditing, ledgering systems, KYC are all things that need to work, but none of it needs to be built internally.

We started Integrated Finance after experiencing the pain building and deploying financial applications. We want to provide a unified and open platform that reduces the time taken to launch and development cost for businesses and results in enterprise-grade quality from day one.

If you’re innovating in financial services, let’s build something amazing together.