How To Combine Multiple Aggregators To Boost Reliability. A Comprehensive Guide for Fintechs.

In the rapidly evolving world of fintech, ensuring reliable bank connections is a critical challenge. A key component in addressing this challenge is the unification engine, a tool that harmonizes data from various financial institutions and data aggregators to provide a seamless user experience.

In the following post, we break down how you could build a unification engine just like we have at Fuse to maximize bank connection reliability for fintechs. We delve into the complexities of choosing the right aggregators, building unsupported products internally, managing API quirks, and handling regular aggregator updates.

Our goal is to provide insights into the intricate process of building a robust unification engine like ours at Fuse. Let's dive in.

1. Securing contracts with multiple aggregators

Some aggregators are not the best when it comes to the speed of handling startup requests, such as procuring production keys or pricing negotiations. This can get dragged out longer than you want, especially if you are trying to build fast.

You don’t need keys to build an initial unification engine, so our advice is to do this in parallel with building out the unification and not to wait until the end.

Another thing to consider is that having multiple aggregators will lead to multiple minimums. We’ve seen MX, Plaid, and Flinks all have minimums, so building with multiple will get expensive.

If you are not okay paying for all these minimums right now, Fuse has partnered with MX and Flinks to offer no-minimums for day 1 so you can offer multiple aggregators without breaking the bank. Book a call with us and we can explain a bit more about our relationship with other aggregators.

2. Building Unsupported Products Internally

The Need for Building Unsupported Products

The reason you will have to do this is that some of the most reliable aggregators do not support some products. So even though that aggregator might have great success rates for auth, balance, and transactions, it might not have the other products you desire.

Examples of Unsupported Products

If you need asset reports for example, Teller or MX in the US do not support this.

You will need to build this out yourself using their balance and transaction data which can be very cumbersome if you are trying to build quickly.

If you are not interested in building out your own products just to unify book a call with us, we have built out products on top of aggregators so you don’t have to.

3. Creating a User-Friendly Bank Search Component

First step, you’ll need to get a list of all the banks across the different aggregators and store these so you can actually display them with your search.

One issue to note here is you will have to remove all banks that are duplicated across the aggregators. You’ll want to remove these; otherwise, your end-user will be very confused why 6 sort of similar banks appear.

Note that this does require a lot of manual work as not every aggregator calls the same bank exactly the same name, and their links will not match either. At Fuse, we had to do matching for around 500 institutions to match duplicates.

4. Handling Regular Aggregator Updates

Sometimes your users will complain that they cannot link their banks to an aggregator they were able to a week ago.

One reason this can happen is if you are assuming that the aggregator still supports that institution or that the institution has not deprecated an endpoint like identity.

To ensure that you are not showing banks that are either no longer supported or maybe they have removed specific product support, you’ll have to run weekly jobs that will check and update what institutions and products are still supported for each aggregator to not disrupt the user experience.

5. Managing API Quirks

Watching Out for API Gateway Timeouts

If you are using serverless, for example, the timeout limits can be very small in some cases 30 seconds. Some aggregators can take up to 5 minutes to return you the balances, for example, which means you’ll have to build a retry mechanism.

Here is what that would look like: if there is a timeout and you haven’t received the balance yet, you’ll need to cache the state of the request, i.e., has the balance been fetched or not yet.

This way, when you do the retry, you are simply checking the cached request state and not trying to recall balance again as this would be very expensive.

Building for Asynchronous and Synchronous Aggregator APIs

Plaid and Teller, for example, are synchronous, but MX, for example, is async, and so you’ll have to create a generate response handler that takes both of these cases into account.

Handling Cached Balance within the account object

For some aggregators, you’ll have to do additional checks to see if the account details contain the latest balance. If it doesn’t, they have to make sure when you are running “transactions get,” for example, that you also update the

Accounting for Signs for Ingoing vs Outgoing Amounts

Teller is negative for outgoing, whereas Plaid is positive for outgoing, and some will not even use signs, which means you'll have to use other transaction data to figure out the direction of cash flow.

This is a big issue for obvious reasons. If you are hardcoding for only 1 of these formats, the data on your end-users end is not going to make any sense, so it’s super important that you know how each aggregator deals with signs so you can unify it correctly.

This is a big issue for obvious reasons. If you are hardcoding for only 1 of these formats, the data on your end-users end is not going to make any sense, so it’s super important that you know how each aggregator deals with signs so you can unify it correctly.

6. Reconnections

Building a Robust Account Fingerprint

Chase, for example, will not return you real account and routing numbers for security reasons for certain aggregators.

This means that when you are reconnecting, Chase will create a new substitute account number for that account if you end up linking with a different aggregator - see more information about that here

Why do you have to worry about this? When you are reconnecting a user, you won’t be able to use their account numbers to match the newly connected with account data you already have about them so you could end up having duplicates appear on the end users end. This is because your system thinks if a new user.

Chase being the top institution in the US you’ll have to take this into considering. If you don’t solve this, you’ll have to get the user to clarify which accounts are the same account so they can match it for you. This is an unnecessary step on the users end that will lead to confusion.

Note: Make sure that you use more than 1 bank account attribute when coming up with an account fingerprint.

Handling Transaction Duplications

When the user reconnects with a different aggregator, all the transactions will have different IDs, which can lead to having duplications in your UI that your end-user is going to see and could affect any analytics you’ve set up.

When you are building for transaction duplication, you should take these things into consideration:

1. Transactions can go from pending to posted, which can entirely change the amount and the date on the same transaction

2. You’ll need to know which account the transactions are matched to, and because the accounts have different IDs (for chase as we talked about), you’ll need to use your previous account fingerprinting logic for it.

7. Choosing the Best Aggregator for a Selected Institution

This is probably one of the most important points to consider when building your unification engine as linking a bank account is often placed during the onboarding process where a user is most likely to drop off.

This means that a user should either be able to find their bank or connect to it seamlessly, and choosing the correct aggregator for an institution is, therefore, paramount. Here is a breakdown of 2 different ways to approach this.

An Okay Solution - A Static Aggregator Rank

Hardcode a ranking for the aggregators for individual institutions based on reliability metrics returned from the aggregators.

The issue with this lies in the fact that the connection rates are constantly changing, which means you cannot just rely on one being better than the other based on a snapshot of reliability data from a couple of months ago.

A Better Solution - A Dynamic Aggregator Rank

Collect as much connection data as possible from your users; this includes disconnection and other success metrics from products like balance, transactions, etc.

With this data, you want to use it to AB test individual aggregators against each other, i.e., For every 90 chase connections with Plaid, do 10 with Teller, 10 with MX, for example. Then you’ll have to run a daily calculation that can use that day's connection results to determine the new ranking.

The Role of Statistical Significance

If you don’t have the luxury of having statistical significance, then this approach will not make too much sense.

For this to work, the quantity of data is key. So if you have a couple of thousand users going through your onboarding every month, then you should reach stat sig on at least the major institutions.

At Fuse, we are using the connection and disconnection data from all of our users to feed into our ranking. So fintechs using Fuse that only have 100 sign-ups a day are able to get the best reliability because of the help from fintechs in our network that are doing 100,000 a month.

Conclusion

Building a unification engine is a complex process, involving numerous considerations from choosing aggregators to managing API quirks. It requires deep fintech knowledge, robust technical infrastructure, and continuous adaptation.

If you are considering unifying bank aggregators, then you are fully aware of the brick wall that your users are facing during onboarding and whenever you need their account information.

At Fuse, we've eliminated these brick walls for you. We've built a robust and reliable unification engine with intelligent routing so you didn’t have to, allowing you to focus on developing your core features and delivering exceptional value to your users and not focusing on maintaining bank connections.

If after reading, you are not keen on unifying everything yourself and want to try Fuse instead so you can focus on building awesome products, tap here to check out Fuse connect in action with our self served sandbox or book a call with us if you have more questions you’d like answers to.