A little over a year ago, bank regulators published new proposed guidance on managing third-party risk. One of the more controversial topics in this guidance is whether a data aggregator needs to be considered a third party by a bank. A data aggregator is a company that gains access to a customer account at the request of the customer and uses this access to help customers centralize their banking into one interface. This access can be via an API provided by an Internet banking site or can use screen-scraping if an API is not available for the desired functionality of the aggregator.
The proposed guidance clarifies that the level of due diligence should depend on the level of formality of the relationship between the bank and the aggregator. If there is a formal written contract of any kind in place, the aggregator would be treated by the bank’s third-party management program like any other vendor that has access to customer data. But what about if there is no contract in place?
The FAQ section of the guidance states that when there is no contract in place with an aggregator, the banks must still perform risk management. It further states that banks should implement controls to identify the source of large-scale screen scraping activity, then perform due diligence to assess the source. This aspect of the proposed guidance has garnered a lot of discussion, and it will be interesting to see if it appears in the final approved guidance. If it does, banks will need to discuss this with their Internet banking providers to ensure the proper data is available to identify the source of the screen scraping. Banks will also need to add these aggregators to their third-party management program and determine ways to block the scraping activity if the aggregator is determined to be a high risk.
Looking beyond assessing the third-party risk of aggregators, institutions should also consider the risks of general aggregation activities when performing their internal risk assessments. Some examples of risks that should be considered are:
- Do Internet banking sites require aggregators to provide customer MFA responses when initiating the connection? If not, the aggregator system can be used to launch a password-stuffing campaign.
- Does the Internet banking site mask sensitive data (account numbers, social security numbers, etc.)? If not, the aggregator may collect more data than the customer provides to them directly.
- Are transactions that can be performed by an aggregator limited? If not, an aggregator could perform transactions outside the scope of what a customer originally intended.
- Can the institution differentiate between normal aggregator activity and malicious activity that uses the same methods as aggregators? If not, attackers can use this technology to gather customer data or perform unauthorized transactions.
If you need help managing internal or third-party risk, please reach out to us any time at support@bedelsecurity.com.