There are countless mobile apps available to help consumers manage their household budget, centralize their financial accounts and achieve their personal financial goals. Some of the more well-known financial aggregators are the common applications that consolidate balances and transactions from your conventional bank accounts and are sometimes described as the “connective tissue” for open banking. For banks, they serve as a mechanism to share financial information and allow for increasingly disparate financial services to acquire visibility across a centralized data hub for consumers.
While financial aggregators serve both consumers and banks well, they are also frequently weaponized by criminals who want to take advantage of the trust model and leverage their data for illicit activity. Suddenly, the assumed to be innocuous and well-behaved fintech with low potential for abuse can be exploited and ultimately sow the seeds of distrust within the system that requires the confidence of its utility.
Let’s discuss how aggregators can be used in a trust model. Assume that an aggregator is provided easier access to a webpage by relaxing security controls as the aggregator is a trusted ecosystem participant. That is, if I am the aggregator, I have a copy of your online baking login credentials, provided by the end user and that might be all I need to do my job. This is one element of trust on the user side: they give their online banking credentials.
On the bank side, any unusual login might be met with a two-factor authentication (2FA) challenge controls for every new access point (new IP address, device, geolocation, etc.), and aggregators are unable to get this code and apply it, as they are robots outside of the channel where the 2FA will arrive (some aggregators have acquired a process for a 2FA initial validation challenge, but this is not the rule, to be clear). So, the banks may whitelist this aggregator’s endpoint and not require a 2FA challenge at login.
This is pure opportunity for a clever attacker.
An attacker that acquires a user’s online banking login credentials via the usual methods – phishing or website spoofing, email takeover, malware, or social engineering – will then have enough information to use an aggregator under the user’s control, to acquire sensitive information about an account. This could be account numbers, balances and deposits, types and names of accounts and perhaps even personal details. This is essentially paydirt for any attacker who needs this data to set up counterparty debits from other financial accounts they control.
Account verification is often executed In the United States through a process called micro-deposit validation which allows for banks to perform remote transactions between accounts. This is a common process when setting up direct deposit for example. Two small deposits, usually under one dollar, are deposited into an account, and then the user is asked to verify the exact amounts as an out-of-band authentication step. Once the deposit amounts are validated, the accounts are linked and they can be used to move money back and forth without much additional challenge, frequently being able to initiate both credits and debits between accounts. What is surprising is that the amounts that can be initiated is sometimes astonishingly high given the lack of friction to link accounts and perform these financial transactions.
As it relates to aggregators, these tools can provide an attacker with an account number and will have a record of deposits made. It will also not be challenged by MFA in many institutions. Thus, an attacker would be able to link an external account at another financial institution on a victim’s account, identify the account to target (and the current amount in it!) via the name and account number, initiate a linkage against that account by sending and validating microdeposits, and then finally, execute a debit from the counterparty account. By the time the institution where the transaction originated from identifies the loss, the attacker is long gone with the illicit funds, and the originating institution is left holding the liability in the dispute.
This is only one example of how criminals can take advantage of the trust model within the open banking ecosystem. We have already witnessed this trust being exploited for credential-stuffing attacks.
There’s only so much trust to go around. As financial institutions who are ultimately victims realize they are being targeted or abused, they can choose to increase aggregator friction to the degree where they may remove the potential for any access at all. As a practitioner, I saw many of my peers take this position and eliminate access and/or maintain higher-risk peer institutions and fintechs in watchlists.
With U.S. banks facing increasing pressure from the Consumer Financial Protection Bureau (CFPB) as it pertains to compensating victims of authorized payment fraud scams on P2P networks such as Zelle, there is concern about the evolving role of liability in the event these data aggregators are used in an attack. The CFPB has not yet addressed liability in this instance.
This is an open issue that should be on the radar of every financial institution. It is definitely one I will be keeping my eyes on.
