Data Aggregation Business Models & Future use cases
The origination of this article came at the back of many points that have surfaced lately. Be it Visa's called off acquisition (of Plaid) to Visa's 2nd attempt at acquiring a Plaid-look-alike called Tink, Yodlee (Plaid's competitor) sold-too-soon dilemma and the latest of the lot - Account Aggregator went live in India (which is on similar lines to that of Plaid).
All these service providers from Plaid (US), Yodlee (US), Tink (Europe) and Yodlee Finsoft (India) are data aggregators that connect to the source bank accounts (assets and liabilities) of the customer and make the data available to any number of seekers (as approved by the customer) to make use of the information for providing a richer CX to the customer.
The western counterparts are more mature when it comes to the architecture and the mechanism to connect the user accounts to the information seekers because of 2 reasons, one being the sheer number of banks and credit unions out there in the west and two, there being no open standards used by these financial institutions to make the information accessible over API. Compared to this the Indian account aggregator (AA) framework is an aggregator of aggregators i.e. it's a layer on top of all the financial relationships of the user with a standardized API suite to make this information available to prospective service providers (to the user).
Plaid Business Model
The founding story of Plaid is not any different from other scale worthy pivoted startups. It was found as an expense manager / personal finance manager and found it super difficult to get automated reports to the user from their bank accounts due to an un-standardized API/No API provided by Banks for the users transaction data.
That was the aha moment when they realised that this problem is being faced by many others and then the pivot to being a Financial Data Aggregation service provider happened.
Plaid business model is rather simple, they have established connectivity to a host of financial institutions in a secure way which they then use to pull the data related to balances, transactions etc. and share it with any application that would require this. The connectivity can be thought of being similar to an OAUTH (Sign in via Google) button which when clicked opens up the embedded web-page/iframe of Plaid and once the user authenticates themselves with Plaid, the connectivity gets established.
What Plaid does not do is it does not establish any API integration with (most) banks. Rather it asks the user to enter the user ID and password of the bank account on an emulated web-page of the bank within the plaid system so that Plain in turn can access the bank account, once done, it scrapes the information available there and stores it at their end. This connection will terminate the moment the customer changes the login credentials of the bank account.
This seems rather archaic and too insecure because the customer is sharing login credentials which apart from viewing information can also be used to transact on behalf of the customer. It is because of this reason many banks that Plaid claims to be onboard on the platform were surprised to see their bank account information (of the customers who signed up on Plaid powered apps) available on Plaid.
This system though archaic works well due to unavailability of open standards for sharing customer data across the ecosystem with customer consent to ensure better access to financial services on account of richer data being available for the financial institutions. Many service providers of the likes of Venmo, Robinhood, Acorns use the services of Plaid to connect to users bank accounts.
Plaid is free for the user who links their bank accounts with Plaid. It charges the prospective service providers who want to access the users bank account on a per API call basis. For e.g.