A 1033 Implementation Breakdown (Part 4)
Digging into the proposals for how data is made accessible, and expectations for third parties
The saga of Section 1033 continues here at Fintech Compliance Chronicles! This week it’s a double whammy, as we dig into two key subparts of the proposed rule, which when combined make up over 100 pages of the rule. Clearly, these two sections (Subpart C - “Establishing and Maintaining Access” and Subpart D - “Authorized Third Parties”) are the meat of the CFPB’s future vision. You might be curious since we’ve devoted almost a month to this - when will it all end? We plan to put out one more assessment of the final part of this proposal along with some closing thoughts, before moving on to other regulatory pastures. Now let’s get into it!
We’re really getting into the nuts and bolts here. The CFPB starts off Section C by focusing on an old favorite - interfaces, and specifically laying down their expectation that data providers (aka banks, financial institutions, etc) should expect to make them available to developers (any institution subject to this should already have a consumer interface, which is another matter). They also make it clear that consumer interfaces can’t substitute for developer interfaces, especially since they want to avoid any possibility of data providers trying to fall back on screen scraping to try and meet the requirements of the rule (my analysis is that this should be a limited scenario, since many large institutions in particular already despise screen scraping due to the potential security risks, and clearly, so does the CFPB).
There are some exception-based scenarios that get touched on - one is “tokenized” screen scraping, which tries to mitigate the risk of a customer’s institution account and password being used but is ultimately still seen by the CFPB as insecure; another is converting data to human readable form without a developer interface, and online banking interfaces in combination with mobile banking interfaces, which the CFPB doesn’t disqualify as interfaces but asks for feedback on.
There is an expectation that data should be made available in machine-readable format, with the main objective being to allow consumers a degree of data portability.
The topic of fees comes up as a potential hindrance to access. It should seem obvious that charging consumers access for their data is wrong, but they acknowledge there are layers to this. What about fees in general, and if they believe there’s a reason to charge third parties for access to the data? As long as it isn’t excessive, what’s the big deal? There are costs to maintaining this data after all; however the CFPB notes the risk of competition especially for third parties becoming limited.
Regarding the aforementioned developer interfaces, the CFPB talks about the following:
a) the format - data should be made available via the dev interface in a format that is standardized and more importantly, readily processable by third parties large and small, “old” and new. The CFPB notes that getting to a fully standardized format for developer interfaces on day 1 would be unrealistic for a variety of reasons, but opens the floor to take comment on whether there should be some alternatives along with whether this part of the proposal deserves more time for implementation.
b) commercially reasonable performance - it was noted that consumer interfaces are typically more reliable than developer interfaces, which is what drives the CFPB to focus on performance here.
1) minimum performance specs - we start getting into some real numbers here. The CFPB sets the minimum expectation for a developer interface to be commercially viable at a response rate of 99.5%. How did they come up with this? They cite the fact that “a number” of data providers’ response rates meet or exceed this, and also that Australia and the UK have established the 99.5% amount as well. However I’m not sure if I buy this, as the latest data from the UK suggests a rate closer to 98%.
“Proper” - as a subset of the response rate discussion, the CFPB takes a little detour to define “proper” response rate as one that a) fulfills the query or explains why it wasn’t fulfilled b) complies with 1033 requirements c) provided in a reasonable time. The CFPB then proposes a maximum response time of 3500 milliseconds. Per Sentry, one of the API tracking/monitoring sites/tools out there, excellent response time is between 0.1-1 seconds. So 3.5 seconds is right in the ballpark of average, which makes this a fair baseline by the CFPB. While on the topic of response rate, the CFPB also brings up the topic of scheduled downtime, and seeks more input on this.
2) indicators of commercially acceptable performance - not content with just setting up the 99.5% number, the CFPB notes that from their perspective this is a minimum baseline, and from what they understand not even that commercially viable. To really make things competitive (trust them, they really are), they propose two additional baselines that would essentially be above and beyond this number - one based on a future industry standard, and another based on actual performance from similar organizations. They also ask what other baselines they could try to align everyone against (this seems a bit comical to me, honestly).
c) access cap prohibition - here the CFPB talks about organizations generally not being allowed to limit the number of API calls a third party could make of a data provider, with the caveat that organizations need to ensure that they don’t get overloaded with calls so some mechanism to prevent this is suitable. The risk, however, is that consumers may get shut out directly or indirectly as a result of caps; one idea the CFPB suggests is to place limits based on size, as smaller institutions are probably more likely to be impacted by any potential hit to their developer traffic or consumer traffic.
d) security specifications
1) access credentials - this section takes yet another shot at screen scraping, specifically by calling out the fact that too many institutions still receive requests from third parties based on authentication that the consumers has presumably provided them by entering their username and password somewhere.
2) security program - the stakes are high regarding the development of a robust developer interface. To that end, the CFPB has cited the GLBA (Graham Leach Billey Act) Safeguards Framework as their source of truth for institutions/providers to develop a compliant security program. This is suitable for those institutions that are federally regulated; for those that are not the CFPB proposes the FTC’s safeguard rules as governing their data provisioning.
The CFPB surprises in the next section, by essentially allowing data providers to deny access to covered data on the basis of factors identified in a risk management approach. To me, this is a big deal because regulators have typically frowned at the usage of the word “risk-based approach,” in my personal experience. However, here the CFPB is essentially realizing that to not call this out would be to shoot their interagency guidance on third party risk management issued earlier this year in the foot; as the purpose of denials would be to prohibit risky third parties access to consumer data. At the same time, while the CFPB notes the benefit to the consumer of being protected by a more potentially restrictive environment, it also points out the potential of competition becoming limited.
In that vein, the CFPB validates a scenario where data providers would have the right to push back on third parties trying to access data via APIs when their own security and even performance standards are substandard. They also point out that smaller data providers risk being overwhelmed with massive amounts of requests for information from tons of third parties. One solution they pose to both of these problems is the usage of certifications, credentials, or leveraging the same standard setting bodies referenced previously; with the idea being that it would support the concerns of the data providers while also ensuring third parties (and ultimately customers) aren’t discriminated against.
Digging in deeper into what third parties are expected to provide to appear reasonable when interfacing with data providers, the CFPB expects third parties to a) be able to authenticate themselves, including by legal name if necessary and b) having contact information available. Maybe a website would help (sorry, but I have to say having a website as proof of identity is a bit dated). While recognizing the challenges third parties and data providers have in trying to create infrastructure to support this means of authentication, they also propose the idea of potentially creating a registry, curated from a likely requirement that will be implemented for data providers to share a list of all their third parties using their developer interfaces, along with an expectation that third parties make the information they are making available publicly disclosed (this part is confusing, because isn’t this essentially saying that third parties could make consumer data available to the public?)
The CFPB then lays out a few scenarios for data providers responding to requests:
Direct requests from consumers - obviously if consumers request their own data, all they have to do is authenticate themselves and make clear the scope of their data. This is something that should be easily accomplished using existing consumer interfaces.
Requests from third parties - some of what is covered here is repetitive, but the CFPB notes that one option data providers have if third parties are challenged to authorize correctly, is to get additional verification from the consumer. After all, the entire exercise is for their benefit!
Conditions that would need to exist for data providers to be able to respond to third parties - the CFPB lays out four of these:
Sufficient information to authenticate the consumer’s identity
Sufficient information to authenticate the third party’s identity
Acknowledgment of authorization procedures (perhaps via disclosure) - my comment, this bit seems a bit redundant?
Sufficient information to validate the scope of the data request
Confirmation of third party authorization - this expands on the point raised earlier about consumers getting involved in the authorization process for third parties to obtain their data, focusing on them confirming the account and the category of data that needs to be accessed.
Two additional scenarios are raised where the data provider doesn’t have to respond to the request for data - one, when the developer interface is not available (I.e. for maintenance/downtime) and second, when the authorization is invalid because a) the consumer revoked the third party’s access b) they’ve told that to the data provider or c) the original authorization expired
Jointly held accounts - in an interesting scenario, the CFPB notes that in the proposal it currently allows any one of two account holders that jointly hold an account to authorize access to a third party, with a call for comment on whether the other account owner should get a heads up, and furthermore whether such benefits should extend to a credit card authorized user (I’d argue no, since historically authorized users are associated with the card for literally just that, authorized usage - not account maintenance, not rewards, not balance transfers, etc).
When a consumer can revoke a data provider’s access to its data - the takeaway here is that consumers or their data shouldn’t be permanently disrupted by their own request to revoke access for a specific third party. Also, data providers should inform third parties when consumers have revoked their access. One of the concerns raised is where the burden of processing the revocation should lie; and it’s noted that the consumer could inform the data provider or the third party directly, both of which concern the CFPB as potentially being onerous for each type of entity. They also call out the scenario where data providers would offer revocation of access to one type of data, but not another (although personally, I think it’s important to make sure a data provider actually does offer granular revocation ability - while “all or nothing” is fine, consumers should be able to have specific controls over how much or how little they can revoke, and I’m surprised the CFPB doesn’t cover this further).
It wouldn’t be a regulatory rule-making proposal without the words “policies,” “procedures,” or “disclosures” popping up somewhere, and now the party gets started as the CFPB proposes that data providers need to offer up certain information about themselves alongside their developer interfaces. Specifically, one piece of this is how the developer interface works. This would help third parties be able to figure out how to use the developer interface and according to the CFPB, would also help them in their “market monitoring” and allow standard setting bodies to come up with the population of data providers. (I find that to be a bit of an excuse to prescribe more work for the data providers; wouldn’t the CFPB already know who’s out there by the fact that they already are regulating these institutions? And wouldn’t the standard setting bodies already have an existing inventory of providers?). I feel a bit better when we get an idea of what they mean by the word “information” with what follows:
Readability requirements - should be as accessible as anything on a public website, and with compatibility for machine readers (nothing new given what has already been noted in the document)
Identity and Contact Information - this is the part which seems a bit extra to me, but oh well.
Developer Interface Documentation and Access Location - now this I can get behind. All the fields and metadata that a third party would need to be aware of should be disclosed so that they can use the interface.
Interface Performance Metrics - this is yet another request from the CFPB that seems to be built only to aid their “market monitoring” - with the specifics being that providers will have to share their responsiveness in percentages. I think most third parties will be relatively uninterested in this since their consumer will have already had data available and doesn’t have a choice - they will need to get the data one way or another. All this might tell a third party developer is how much work they’ll need to do in order to access it. Not to leave us hanging, the CFPB also seeks comments on a whole host of potential future performance metrics to be reported, including request volume, number of accounts, uptime, downtime, and response time.
Policies and Procedures - there’s about ten pages devoted to policies and procedures. Most people aren’t a fan of this, and see it as a necessary evil. To that end, we can summarize what is relevant here:
Be reasonably written
Explain how to handle making data available and responding to requests including denials
Ensure accuracy
Record retention (something I’ve noticed people gloss over historically, but hyper-critical here)
Onto Section D! - which is entirely devoted to authorized third parties.
The section starts off by stating what has already been noted a few times, but will now dive in specifically from the perspective of the third party (to this point and in Section C, most of the perspective has been from that of the data provider itself). For starters, the CFPB explains that for a third party to become “authorized,” while it’s one thing for a consumer to say they authorize a third party, they have to send a disclosure to the consumer, explicitly say in the disclosure they agree to certain obligations, and that they obtain the consumer’s express consent to be able to access their data on their behalf. While of course this is great for the consumer to have transparency about who is handling their data and how, I’d argue this is even more important because from an innovation and efficiency perspective, it gives the third party the green light to run and do whatever it needs to in order to not only obtain the data from any and all data providers, but also ingest it and deliver it in a way that will be of incremental value to the consumer. After all, there wouldn’t be a 300 page proposal dealing with all this if there wasn’t potential for some dramatic use cases for how consumer data can be transformed and re-presented. The CFPB then notes some scenarios where this standard approach may not work in the exact same way, and considers whether exemptions may be needed for smaller or otherwise different types of third parties.
There’s quite a bit that follows regarding the disclosure itself:
How it should be formatted - fairly obvious, but the disclosure should be distinct and easily visible. Some speculation about whether ADA compatibility could be considered.
What should be in it? - 1) the name of the third party 2) the name of the data provider the consumer seeks to get the data from 3) what product/service (or use case) the consumer is seeking from the third party and an affirmation that the third party will only be getting the data to help fulfill that purpose 4) categories of data 5) a certification statement 6) how the authorization can be revoked.
How to account for other languages - the CFPB doesn’t explicitly prescribe a mechanism for this, but it does note that any translation must link back to the English version. That’s the general point, that English is required at any point, and otherwise just that whatever language the disclosure is should jive with whatever language the rest of the communication in (again, goes without saying).
So what are the requirements (or “obligations”) the third party has to follow?
Limiting collection, use and retention to whatever is “reasonably necessary” and only focused on the consumer’s requested product or service - while this makes sense, predictably the SBREFA panel requested the CFPB to allow for consumers to opt into third parties being able to use data for secondary purposes. The CFPB says no thanks - essentially, to them the focus in this process is all about the consumer and anything that seems like it’s enriching the third party at the consumer’s expense, even if the consumer willingly does so, is not going to fly.
What do they mean when they say “reasonably necessary?” - this expands on the point about the consumer being the primary beneficiary of the data collection/use/retention effort. It emphasizes the point to third parties that they basically work for the consumer and without directly saying it, have to have a sort of loyalty to them.
What do we mean by the “requested product or service?” - this gets to “intent.” Consumers are characterized as interfacing with third parties (and by extension, data providers) for a really specific purpose. The CFPB rightly points out that some consumers don’t even know what some of their data is or means, and it’s pretty unfair for third parties to not only obtain this data in that scenario, but then use it without the consumer even being aware.
Targeted advertising, cross-selling, and the sale of data are a no-no - while a third party could argue that a consumer might be in the market for a new checking, credit, or other financial product and this sort of marketing might be of benefit to them, the CFPB isn’t buying this argument, basically telling us “when is the last time consumers actually found a cross-selling/invasive ad to actually lead to them opening up a new product?” From my own personal experience, I can actually agree with the CFPB here. I do my own research when I’m in the market for a financial product based on a personal need or circumstance in my life, and then based on that I address my needs. Advertising isn’t going to sway me over.
What do we mean by “limited collection?” - specifically, this is what the CFPB clarifies:
Limit collection of covered data to what’s reasonably necessary to fulfill the consumer request (has been stated already)
Limit the duration of collection to the maximum duration period (more on this later)
Obtain a new authorization to go beyond the maximum duration period (more on this later as well)
Abide by limitations if the maximum duration is not extended beyond the present authorization period.
Note the “maximum duration” of time third parties have access to data - as a starting point, the CFPB says an authorization and reauthorization is good for one year in terms of a third party collecting data. However, beyond that it seems the CFPB hasn’t really figured this out yet and is interested in feedback on all sorts of ideas here:
Reauthorization happening on the same day/year for all third parties, for all consumers?
Some commenters suggested taking dormancy into account.
Some products may require longer-term access - and this is a complex scenario. In some cases consumers may try to terminate access and fail, and in other cases consumers may want to try and extend authorization beyond the one year and fail, getting frustrated by having to do the reauthorization dog and pony show annually. Unfortunately, without directly saying it, the CFPB essentially tells consumers “tough luck, we’re doing this for your own good.
Note the particulars around reauthorization - the third party can initiate a request to be reauthorized to the consumer. An “annual check in” approach is endorsed by the CFPB, so that the process becomes something cyclical and routine, rather than varied and surprising. Staging this well before the actual expiration of the existing authorization is also highly recommended, mostly so the process doesn’t annoy consumers.
What happens when “maximum duration” meets reauthorization? - in other words, what happens when the reauthorization doesn’t happen? Third parties will agree 1) not to collect covered data 2) not use or retain covered data that they may have already collected (unless something that was related to an earlier collection is still processing). The CFPB uses this as an opportunity to chide the common practice of retaining customer data long after the relationship/authorization ends, which presents all sorts of security/fraud/privacy risks, while noting that in some exceptional cases this might be necessary I.e. for a subpoena or at the explicit direction of the consumer.
Use of the data is “limited” - The CFPB makes it pretty clear and almost re-iterates, that “secondary use” of the data, beyond the initial purpose the consumer sought the data for, is not allowed with the same exceptions noted previously in the reauthorization context, with the additional scenario of needing the data to service the customer or provide them the product. They then seem to clarify their previous comment about opt-ins, by seeking comment on whether there could be a scenario where the opt-in isn’t necessarily for marketing purposes but could be for servicing-related matters.
Accuracy is important not just from the perspective of the data provider sharing the data, but also from the perspective of the third party receiving it - This is implemented through - surprise! good old friend, policies and procedures. The expectations here are around accuracy, meaning data should be accepted in the format established earlier by the CFPB, and addressing any information brought by consumer/data provider/other third parties about potential inaccuracies. Why accuracy of the transmission and not other dimensions of accuracy like specifics of the transactions, product design, etc? The CFPB realizes this data is regulated in so many other ways, so best to stay focused, essentially, and also limit the burden on smaller third parties. Best of all, the CFPB then closes by noting that procedures can be flexible, ranging from mere standards to something more detailed depending on the complexity of the third party (I.e. data aggregator) or product.
Data security expectations - The CFPB reiterates what we heard earlier, that they are applying and expect third parties to comply with the GLBA Safeguards Framework, and in the event it doesn’t apply to them, then the FTC Safeguard Rule. Straightforward, with the intended goal to limit burden on third parties by essentially not re-inventing the wheel.
Providing covered data to other third parties - In what can be described as “fourth party considerations,” sometimes third parties need to engage other third parties to satisfy the consumer request. In these cases, the “reasonably necessary” clause kicks in and consumers would need the same protection they have with the original third party, which is why disclosures are required again, this time from the original third party to the “fourth party.”
Keeping the consumer in the loop - The third party is expected to provide updates to the consumer in several ways - a) making sure they can access past and current disclosures they have agreed to or received; b) be available to answer questions about their own access to consumer data c) be generally available I.e. via a dedicated customer service function d) readily answer questions like “why did you pull this data and how does it satisfy my original request” e) make it clear where the authorization currently stands.
Revoking authorization - there’s some repetition here, but one thing to point out that didn’t get covered previously, was that fourth parties and other parties involved in the data collection/provision need to also be informed (with the fourth parties being the most critical, in my opinion). We also get a heads up that the mechanism by which revocation happens should be straightforward and user-friendly. It should also be something that can happen at any point (not just during the annual “check-ins” that were discussed previously). The CFPB then also reads my mind and lays out the scenario of third parties needing to support the scenario of revoking some authorization (I.e. for one product) but not others (I.e. for another product).
Section D ends with a welcome focus on a different player in the mix - data aggregators!
What happens when they are responsible for authorization? - even though the third party may use a data aggregator to help them obtain the authorization and even the data, the ultimate responsibility for disclosures/authorizations/all the good stuff still sits with the third party. The data aggregator is more or less the tool in that scenario.
Disclosing the name of the aggregator - pretty straightforward - although they aren’t a mystery to third parties and not even to some consumers, so this isn’t really anything surprising.
Certifications for the aggregator - given how hands on a data aggregator could be in the process, the CFPB expects them to give their own certification (an attestation of sorts) either directly to the consumer, or delivered to the consumer via the third party. The consumer doesn’t necessarily get to pick the aggregator involved here, so at the least they should get some comfort from anyone else who is going to be touching their data.
Policies and procedures for record retention - on the third party’s side, this sets out a three-year period during which anything related to whatever the consumer authorized the third party to perform/obtain/collect on their behalf should be retained. Procedures can continue to be flexible for the third party, as noted previously.
~~~~~
Phew! I think I need a brain massage after going through all that! We are pretty close to the end of learning about the CFPB’s vision, but biggest takeaways here is how much scrutiny will be on data providers and even more so, third parties that want to step into the open banking space in the future and try to connect consumers with their institutions/data providers. The bridges are being built, the question is, with the “tolls” being laid out here, will anyone be driving on them?
Join us next week for the final hurrah on 1033. Until then, see you tomorrow for the event roundup!