While I applaud the CFPB’s recent finalizing of the 1033 rule requiring banks to use the FDX standard to make banking more interoperable and competitive, I think their choice of wording to talk about APIs is a missed opportunity. When you read the 1033 rule you will notice that the acronym API was not used, in exchange for calling them “developer interfaces”. Which is something that will backfire and reduce the effectiveness of the rule, ignoring 25 years of business and engineering evolution in how application programming interfaces are talked about and used.
These “developer interfaces” the CFPB speaks of are not just for developers. Application programming interface, or simply API is the formal shorthand for using programmatic interfaces for applying digital resources and capabilities in a growing number of applications, including desktop, web, mobile, device, and artificial intelligence. APIs aren’t just used by developers, and many of us in the space have worked hard to make simple HTTP APIs available for sales, analysts, marketing, and other business stakeholders to use in their work. There is much more to using APIs than developers writing code, and oftentimes the discovery, browsing, and decision to purchase and integrate an API is not conducted by a developer.
Much of the dysfunction surrounding the usage of APIs, from complexity to security concerns are often introduced because APIs are primarily seen as a technical thing. When in reality APIs power 83% of the web and the business that goes with it. Visit Linkedin APIs or Facebook APIs, and you’ll see that the developer portals aren’t just designed for developers anymore, because developers are often just the last mile of stakeholders involved with finding, understanding, and “applying” the useful digital resource where it is needed. With Postman Collections, integration platform as a service (iPaas), and the growing number of low-code and no-code options, APIs aren’t just for developers. Words (or acronyms) matter, and I get that federal government policy often possesses its own language, but the decision to use “developer interfaces” is a missed opportunity that will have significant downstream repercussions.
We need business and engineering stakeholders being involved in the compliance with the 1033 rule. The more you isolate the discussion in developer circles, the more you perpetuate the divide that exists between business and IT groups. The more you speak only to developers, the less business stakeholders are up to speed on what APIs, and the documentation, onboarding, monitoring, observability, terms of service, privacy policies, and other building blocks essential to governing API access. The word phrasing may seem trivial to many, but I read a lot of wonky policy documents, and I get that words truly matter. APIs aren’t just for developers. The 1033 rule is about end-users and investing in their awareness, agency, and control over their own financial data—why would you frame 1033 as being just for developers? APIs are simply about using programmatic interfaces to apply our own financial data in the ways that matter to us-—let’s please stop building walls and use the right inclusive language that your average user will encounter on the open web.
