Evaluating data aggregation on coverage, data types and access methods

Our last article addressed how modern financial apps are powered by user data and how data aggregators differ when it comes to data reliability and cleanliness. Access to financial data drives innovation, as evidenced by new digital banks and new fintech apps.

A new whitepaper by Fiserv outlines five categories of evaluation criteria for selecting a data aggregator. These include data reliability and cleanliness, coverage of institutional sources and data type handling, platform adaptability and support for innovation, security practices, and privacy, transparency, and reliability.

When evaluating a data aggregation platform, it’s important to drill down on the coverage, data types, and access methods it offers. 

Coverage refers to the number of institutions from which a platform accesses data. This access is derived in a variety of ways, from direct FI connection to unstructured screen parsing. One also must consider the domains (e.g., consumer banking, small-to-midsize business activities, investments, taxes, utilities, insurance) from which a platform can accommodate information. Finally, there’s the type of data elements captured, whether basic transactions and balances, meta-data about rates, fees and terms of an account service, or supplemental data such as loyalty points associated with a credit card.

Although platforms may advertise coverage of 15,000 to 20,000 connections across banks, credit unions, utilities, and beyond, these counts aren’t necessarily core differentiators.

“Counts [from marketing] mean nothing to me,” said Bob Sullivan, president of FinancialApps. "Everyone has thousands of them. What it really comes down to is how they count. Is Wells Fargo and its six subsidiary banks one connection, or is it seven?” He finds that the long tail of connections is where platforms differentiate. “If the count expands the footprint of smaller credit unions and banks, then it matters.”

For Kevin Hughes, senior product manager, data aggregation services at Fiserv, this long tail coverage is important for fintech companies’ customer satisfaction.

“As fintechs build their applications to appeal to the broadest possible customer base, they need to ensure accessibility to a full range of financial institutions. This sustains a great overall user experience. While they may not add small banks or credit unions every day, they should have these institutions available if a new user tries to connect tomorrow.”

Similarly, Ryan Christiansen, senior vice president for data access at Finicity isn’t convinced coverage volume is a top concern as “most platform’s core data models are similar.” Instead, he believes a platform’s ability to access needed data is what fintechs should verify. “All solution providers have some degree of specialty,” so source and data type coverage is a major consideration. He advises that fintechs should understand which information elements are mission critical to their application (like tax, credit or bill payment data) and do a gap-analysis with a provider to understand how the data is accessed. Much of the data for small-to-medium sized business financial activity is similar to consumer banking data, and thus also is covered in the integration discussion. This is a growing area of information use.

Coverage increasingly is facilitated through financial industry standards for open APIs. This is akin to the mid-1990s as the market for computers, phones and headphones grew. At that time, technology companies sought a standard for short range wireless communications. Today, over 30,000 brands have standardized on Bluetooth. PwC notes the parallels to data sharing today:

“The secure exchange of data through an industry backed standard could replace the tangle of incompatible APIs and custom data-sharing arrangements. Through the launch of the Financial Data Exchange (FDX), a broad cross-section of banks, Fintechs, and financial services groups have aligned around a single data-sharing standard that could accelerate the adoption of open-banking API frameworks.”

While FDX is just one of several US-centric standards that reflect progress with open-banking API frameworks, the US still lags the EU’s Payment Services Directive (PSD2) in terms of participation and technical specifications. This means that one-off data sharing arrangements

and unstructured, or “screen scraping”, approaches are extant in the US. But direct FI connections in specialized standards like FDX, Akoya and Durable Data offer cleaner, better formatted and more robust data.

“Instead of direct connection, some platforms parse information presented on the screen. This increases data cleansing requirements, grows the likelihood of errors and can impact the downstream product experience,” said Finicity’s Christiansen.

While screen scraping in a legacy sense is problematic in terms of accuracy, reliability and security, the market is migrating away from it. Plaid’s Putnam notes that old-fashioned HTML website parsing is increasingly uncommon. Moreover, many banks including JPMorgan Chase are ending screen-scraping styled access and pushing API-based dashboard connections. But one provider cautions against worrying about platforms’ source access methods altogether. Instead, they suggest focusing on what matters: data quality. “We use whatever means necessary to get the job done right – specifically, to provide quick, comprehensive and filtered data.”