APIContext partners with Akamai to expand advanced API monitoring adoption. Learn more >

Our Letter to the CFPB

APIContext provides enterprises with end-to-end visibility, proactive risk measures, and comprehensive monitoring capabilities for their APIs. The platform empowers businesses to optimize API performance, mitigate security risks, ensure regulatory compliance, and deliver exceptional product experiences.

The Consumer Financial Protection Bureau (CFPB) are currently asking for comments on their proposed rules for Personal Financial Data Rights. We have previously spoken about these new regulations in a previous blog post. These new regulations are extremely important and data privacy is at the heart of our mission. Thus we found it important to send our comments in a letter to the CFPB. Here are our thoughts below:

We are writing on behalf of the merged company APImetrics and Contxt. We are a leading API performance, security, and compliance monitoring platform for API product owners.

We extend our gratitude to the Consumer Financial Protection Bureau (CFPB) for its efforts to establish comprehensive regulations for open banking, including the development of Personal Financial Data Rights. In line with our extensive experience in this field, we would like to offer our insights and recommendations concerning the proposed rules.

Point 1: Real-Time Compliance Monitoring for Open Banking Services

The current proposal stipulates that compliance reports must be delivered to the CFPB on a monthly basis, by the 10th of the following month. However, from our experience in other markets, this interval risks the security and efficiency of open banking services. 

Consider a scenario where a deposit-taking institution releases an update to an existing API on the fifth of the month, which inadvertently includes a security vulnerability. Reporting on the proposed cadence could lead to potential breaches for 35 days, adversely affecting both consumers and the open banking ecosystem.

To address this concern, we recommend that compliance validation should be available on-demand and in real-time for all depositories and third-party financial technology companies. The same API infrastructure used for open banking applications can serve for compliance APIs. In practice, we already conduct real-time compliance monitoring in other markets, which has proven to be both effective and efficient.

This adjustment enhances the safety and security of financial data, supports the seamless operation of open banking services, and ultimately fosters greater trust among consumers.

Point 2: The Need for Scalability Testing

The proposed rules rightly allows banks to prevent specific third parties from accessing their open APIs if the bank has a reasonable expectation of a “bad neighbor” effect from a particular third party. However, without appropriate performance and scalability requirements, the proposed rule could unfairly allow banks to deny popular requestors that are serving consumers.

On an ongoing basis, we measure a wide range of poor-performing APIs that are available for public consumption, including over 300 APIs where we publish open results at https://apimetrics.io/api-directory. We regularly alert teams when we see challenges with their infrastructure not performing under load, even in highly critical use cases.

Without scalability and performance testing, the current draft rules will allow banks to restrict access to under-performant APIs, using the “bad neighbor” risk as a justification. To address this concern, we recommend that banks be obligated to conduct scalability testing and transparently report the results.

Point 3: Standardization and Compliance Verification

We appreciate CFPB’s approach to allowing industry standards bodies to define and refine architectural and access standards.

However, one of the significant issues in open banking adoption is the divergence between architectural specifications and the actual build of APIs. 

For example, consider a scenario where a standards body approves specific technical standards for open banking APIs. A bank, in alignment with these standards, designs an API that complies with the architectural specifications. However, as engineering teams continue to work on the API over time, variances may occur, leading to deviations from the initial architectural specifications. These variances can range from minor adjustments to more substantial alterations, impacting the API’s performance, security, and compliance.

To address this challenge, we recommend that the CFPB require depositors to report on architected specifications for each API and compare them to the as-built APIs. This approach ensures that the standards set by the regulatory body are consistently followed, aligning standards and actual implementations to maintain API consistency and reliability.

Point 4: Performance and Uptime Metrics

The current proposal suggests an average response time of 3500 milliseconds, a duration that may be considered too lengthy in practice, impacting the quality of service provided to consumers. Additionally, the requirement of 99.5% uptime allows of over three hours of downtime per month. Further, the proposed regulations allow for an exception to uptime for planned downtime, with no limitations.

These availability requirements do not reflect the architecture of typical applications. API services are often made up of multiple API calls, which need to be executed in a sequence. For example, a payment transaction may be composed of four separate API calls to authenticate the user; a fifth API call to confirm the user has appropriate access permissions to effectuate a payment; a sixth API call to check the balance on the account; and a seventh API call to initiate the payment transfer. According to the draft rules, the total acceptable time for this transaction would be 24.5 seconds, which is unacceptable for consumers.

Additionally, many services timeout before 3500 milliseconds for security reasons, and if a response is not timely received, the entire sequence fails, which would then require a retry. This would be confusing and unsettling for consumers, and would result in double payments and other avoidable errors.

To address this concern, we recommend that the authorized technical standards bodies, responsible for setting open banking standards, also govern performance and uptime expectations. Furthermore, these metrics should be tailored to different applications and functionalities across a range of open banking experiences. From a practical perspective, in other markets we see 99.99% uptime inclusive of planned downtime; and individual API call performance under 1,000 ms for the 99th percentile of API calls, which we see as a good baseline for positive consumer experiences.

In summary, we believe that implementing these recommendations will further the CFPB’s goal of establishing a robust framework for open banking, ensuring the security, reliability, and inclusivity of financial data services. It is our commitment to support the growth and success of the open banking ecosystem, and we remain at your disposal for any further information or discussion on these points.

Share

Request A Demo

Find A Slot To See A Demo Or Speak To One Of Our Support Specialists

Ready To Start Monitoring?

Want to learn more? Check out our technical knowledge base, or our sector by sector data, or even our starters guide to the API economy. So sign up immediately, without a credit card and be running your first API call in minutes.

Related Posts

Join Us Now!

Join the 100s of companies relying on APIContext.