Orchestration is everywhere
In a long overdue follow up to my last post, Orchestration is the new layer, I want to expand on the instances of orchestration layers, which are more prolific than I first comprehended, and broaden its scope.
The previous post was focused on payment orchestration, but after I connected with a number of people in the space, I realised many of these payment orchestrators are expanding their aperture from “payment orchestration” to something more akin to “commerce orchestration”.
I then began to see a number of other existing startups as orchestrators but in different verticals, leading me to think that there is a broader shift happening from aggregators towards orchestrators.
This shift is occurring because data is becoming more abundant and open, making it more commoditised. In addition there is increasingly more competition in the fintech and even broader software space and with increasing competition comes the need to stand out.
Integrating multiple data sources through a data aggregator is no longer enough. There is a need to build more precise decisioning across previously siloed data sources by using a layer of logic and automation. This is the time for orchestrators.
Orchestrators
To quickly recap the previous post and take broader lessons from it, orchestrators not only provide access to a number of underlying data sources through data aggregators, but they provide an intelligent layer on top of this access, to build custom workflows and automations. The ability to quickly adapt custom logic enables businesses to respond to changing environments and thrive in contrast to competitors with inflexible decision making models.
For example, credit models that could adapt quickly to changing customer circumstances during the pandemic meant that some non-traditional lenders were better placed than banks to weather the storm. More automated lending decisions based on new data sources help lenders not only better understand and differentiate customers but also to reach traditionally underserved customers. A post by McKinsey tells of the impact on lenders during the pandemic of being able to differentiate in the hospitality sector between a restaurant who has not adapted and to one that has shifted to an omnichannel model.
A key advantage for the BNPL industry is that every purchase is approved, allowing them to quickly respond to macro changes unlike banks that generally issues revolving credit like overdrafts and credit cards.
As well as more lender allowing more flexible and precise decisioning, using an orchestrator also provides a speed and cost advantage. Rather than having to build and maintain numerous integrations yourself, you can launch quickly with one integration. The automation of workflows also reduces costly manual processes.
Let’s take a look at some orchestrators in different arena's beyond payments.
KYC / Identity Orchestration
Alloy is an “identity decisioning platform” and what that basically means is that it allows its customers to build bespoke workflows on top of the data sources it offers to identify individuals.
Alloy integrates directly to some sources and also works with a number of data aggregators that provide access to multiple sources of data. Alloy provides access to all of these data sources through one integration (partners such as Codat, ComplyAdvantage, Experian, LexisNexis, OnFido, Socure and many many more (full list here).
Alloy not only aggregates these data sources into a single tool, but provides an interface for a customer to build custom workflows to suit their use case, orchestrating the flow of information to specific routes based on customer defined rules.
This speeds up the roll out of an onboarding journey for customers who only need one integration to Alloy instead of many to their underlying data sources, as well as the orchestration layer of how each data source interacts and how it can be used in a sequence determined by end user actions. The interoperability of multiple data sources can lead to a more precise onboarding journey that can result in fewer rejections. Onboarding is only one area in which Alloy can help customers as it also has solutions for credit decisioning and ongoing transaction monitoring.
One example of this is Coast, a fleet and fuel card who is a customer of Alloy for onboarding and underwriting. Coast has automated its multistage onboarding and underwriting process using Alloy to not only process applications within five minutes but to also reduce fraud losses through a combined KYC, KYB and fraud flow. You can read more about how Alloy partnered with Coast here.
Customer Data Orchestration
Another example of orchestration would be Customer Data Platforms (CDP’s). These platforms connect to multiple sources of first-party customer data and interactions (website, email, social media, customer support, commerce etc) and create a single customer view in a central dashboard that can be used to orchestrate customer engagement. Segment is a great example of this and you can check out more here.
Through integrating with multiple first-party data sources, customers building on top of CDPs can create more personalised consumer interactions based on a holistic understanding of the entirety of a consumer journey.
Credit scoring fintech ClearScore uses Segment to create customised scoring tools dependent on geography to support the global expansion of the business and to then maintain those tools. These tools needed the flexibility to integrate with existing marketing tools and still be familiar to horizontal platform teams that support multiple geographies. Read more customer stories here.
Payment & Commerce Orchestration
The previous post described payment orchestrators in detail but I missed a larger trend of some payment orchestrators moving beyond payment orchestration to a broader vision of commerce orchestrators, of which payments is only part of.
Orchestrators such as Primer and WhenThen (amongst others) are starting to build automated workflows to manage post-payment events (shipping and returns) or customer engagement (customer loyalty and customer service).
Orchestrators like these look to become the one stop shop for online commerce players to run their business by coordinating and automating actions across previously disparate systems. An example of this is Shopify, who provide commerce orchestration services for the customers on their platform that allow businesses to sell, ship and promote their products through the Shopify Platform. Shopify also has one of the best checkout experiences in e-commerce, where they now make over 50% of revenues.
For most fintechs, this shift is partly economical, profitability in payments only comes with enormous scale, but also because of customer demand.
Orchestrators vs Aggregators
Orchestration is similar to aggregation but the former goes one step further.
Aggregators tend to be a more commoditised product that allows a customer to gain access to multiple data sources with one integration. An example of a commoditised aggregator sector is open banking platforms that allow a customer to have access to multiple bank APIs through a single integration.
Orchestrators take this one step further and build software to create and automate workflows across different data sources with a visual UX.
Using the open banking platforms as an example, if they were to offer their customers the ability to create a workflow to automate the movement of money from an end customers bank account to a savings or investment account, that would be more akin to orchestration. Currently, this would have to be built by the customer themselves as open banking platforms are aggregators and not orchestrators.
Astra is an example of a company building this type of orchestration functionality in the US and work alongside Plaid to get users historical bank transactions. With the prevalence of real-time payment systems in the UK and increasingly in Europe, this type of service would be even better. The development of Variable Recurring Payments (VRP) largely solves this use case.
Why is this shift to orchestration happening?
The examples above are a move more broadly to an If This Then That (IFTT) orchestration model which is rules-based and can automate workflows across different data sources.
Aggregators have two potential opportunities to differentiate. The first is to expand and connect to more data sources than the competition and build a moat around connectivity. The second way to build a differentiated product is to move up the value chain and layer on top of data sources an intelligence platform to make data more useful. This is a natural evolution for aggregators and a new category that is being created. It is very difficult for a company to pursue both strategies.
Data aggregators
Data aggregators came about because of the increasing need for a company to integrate its software with many others through APIs and these integrations were becoming increasingly difficult to manage as their quantity increased.
In the fintech space specifically, open financial APIs were first mandated by regulation in Europe and more slowly by market forces in the US, and gave rise to open banking banking platforms such as Plaid, Tink, Yapily and TrueLayer (not exhaustive). These providers connected to hundreds if not thousands of underlying banks so their customers didn’t have to. They could build just one integration to the platform.
Aggregators that provide access to data, like the open banking providers named above, typically specialise in a narrow dataset and are often not exhaustive for what a fintech needs. The data they provide is typically of one type, i.e. bank account data but not investment account data. They are also often geographically limited which makes it difficult to build for a multi-geo customer base. As the world is becoming increasingly globalised and our financial lives more complex, this created an opportunity.
For example, if you want to build an identity verification solution for a customer that wants to accept any customers from around the world, you would likely have to stitch together a number of underlying data sources to do this as data providers might only specialise in address verification or only in document verification. On a different dimension, they might only be able to verify customers in the US, or Europe or even narrower, in one particular country. This results in the need to stitch together a patchwork of solutions to solve the problem. This gave rise to aggregators.
As the move towards “open finance” and “open data” more broadly continues, there will be more sources of data to be opened up. Investment accounts and insurance to name just a few that might be in scope for “open finance” in Europe.
Existing aggregators will likely look to provide access to these new data sources as well but this is not where the value is accruing.
Orchestration: an intelligent workflow layer
With more and more data sources available through open APIs, there will be a need to create workflows across different sources based on flexible logic. Creating this intelligent orchestration layer will be where the value accrues.
Aggregation of data sources, especially in Europe where financial data is likely to be mandated to be created, and if forced to be made available for free, will likely mean that access increasingly becomes a commodity and there will be a race to the bottom in terms of price. It is hard to build a moat around this sort of data.
Orchestration is nothing new. Banks and other financial institutions would have had to have these sort of workflow layers built internally to bridge the gap between their siloed legacy architecture and make it more interoperable.
However this would almost exclusively be done internally for the bank’s own benefit. But given the breaking down of the financial services stack into modularised components and data sources, there is an increasing need by fintechs and others that offer financial services, to have these composable layers work together.
Orchestrators do just that as they seek to create value beyond providing access to different data sources using a modularised architecture that allows for flexibility.
Plaid x Cognito
Many companies are moving up the stack to add value beyond access to data. Orchestrators either start fresh by building integrations into data aggregators and then layer on the orchestration layer. Or it could be that an aggregator expands and decides to move up the value chain itself, morphing into an orchestrator.
Plaid is a good example of a company that I believe is doing this with its acquisition of Cognito. Plaid’s traditional business provides data on an individuals financial life, which is just one facet of their life and identity. Users verify their identity by providing them online banking credentials through Plaid Link which then allows Plaid to access their financial data.
This identity verification has a lot of parallels with Cognito’s identity verification and KYC product and could point to ambitions beyond bank account data. By layering on other data sources (card data, payroll data, insurance policies etc) beyond bank accounts through one simple user verification layer powered by Cognito, Plaid could power many different use cases and orchestrate across the different sources with an automated workflow. The user experience is key to the success of this and minimising the friction. Verification should only occur once and provide access to multiple different sources of data, resolved back to the single identity. Multiple different log in’s and access screens won’t work.
An example might be that Plaid works with a lender who wants to make consumer loans. Powered by Plaid, the lender could ask its borrower to verify their identity and then to provide its bank account history as the primary basis for underwriting (cash flow underwriting). But if this didn’t meet the lender’s underwriting requirements, the lender could create logic to run other checks against payroll data or card spending data to provide them with the comfort to make the lending decision. The power to orchestrate across different data sources from a single end user, a borrower in this instance, can change a lending decision from a no to a yes and also reduce likelihood of default.
Conclusion
Yes a customer could build connections to the data sources themselves and build the orchestration layer internally, but maintaining those connections and the logic overtime takes resources for what is a non-core activity.
A lender’s competitive advantage for example, its secret sauce, is in its credit underwriting model and not in maintaining data connections and an increasingly complex workflow layer between different data sources. Banks don’t update their credit models very often and as we have experienced over the past two years, the world can change a lot in that time and so a flexible, modular approach provided by orchestrators is needed.
As data becomes more abundant and open, it may not be a long term advantage. Turning data into information and intelligently orchestrating across different data sources will help build more precise decision-making that can be a strategic advantage over the long term.
Special thanks to Edwina Johnson and Yasamin Karimi for providing support and feedback on this post.