I’ve read rule 1033, and played around with the Financial Data Exchange (FDX) API, and I am working to expand my knowledge of what is happening around the financial API regulation coming out of the Consumer Financial Protection Bureau (CFPB). To guide my work I would like to create an APIs.json blueprint to showcase what is possible with FDX and 1033, expressing the business details as an APIs.json and the technical details as an OpenAPI. Unfortunately due to FDX’s OpenAPI not being publicly available, and the restrictive API licensing that exists around the “open” specification, I am unable to do this. However, thankfully there is one “application” of FDX that I can showcase from Mastercard, via the Mastercard Developer Hub for FDX APIs.
While I am not pleased about FDX’s old school approach to open API standards, and their OpenAPI, I am very pleased to get to showcase Mastercard’s approach—-because it exceeds what I would have done on my own with just the FDX OpenAPI. Mastercard demonstrates all of the technical and business blocks that financial providers and banks should emulate. I am not kidding, they have more than I would have known to include and provide an excellent blueprint for others to follow, or my recommendation would be to just use their implementation. To guide my learning I created an APIs.json blueprint of Mastercard’s approach to delivering FDX compliant services via the Mastercard Developer Hub for FDX APIs.
There is so much goodness in there to unpack. They offer two separate APIs, one for authorization and on for resources. Each API has documentation, an OpenAPI, mock server, and GitHub repository for each API mock server implementation. Then there are a whole suite of common properties available to support both APIs. A few of the properties overlap with Mastercard’s other APIs, but for the most part all of these properties are dedicated to the FDX APIsd—providing a rich blueprint for modeling FDX API implementations beyond Mastercard (or just use theirs). I also think there is a wealth of things to learn beyond just FDX, and I think their approach is worth modeling when it comes to other busienss sectors. I have grouped the common properties and commented to try and think more constructively about how I can iterate on the blueprint, and evolve some API Common schema to better support.
Some of the properties included in the Mastercard Developer Hub for FDX APIs blueprint are pretty run of the mill, but the way their showcase the standards behind, the regulation associated with it, and utilize Postman workspaces, collections, as well as providing a Docker container—are pretty forward leaning approaches worth studying more. I’ll use their approach to referencing standards to evolve a formal standards schema for API Commons to group all the underlying standards into a single machine-readable property. The way Mastercard links to regulation as part of the API discovery document is also a new property for me. The combination of a Postman Workspace, Collection, and guide to properly using Postman isn’t new, but the way they use Postman to validate, test, and certify implementations is very forward leaning stuff. I have to give it to Mastercard, they have done a pretty stellar job at delivering a robust FDX solution.
Plaid and Stripe have FDX offerings, but they aren’t as robust and out in the open as Mastercards, but I will profile them as well so that I can do a diff. Beyond that there are really NO other interesting implementations. I am sure there are some out there I can’t find with a little Googling, but the search listings are just filled with hot takes, and now the legal battle that is emerging from banks. I can’t help but think that the discussion, storytelling, and demonstration of what is possible with FDX is being stifled because of the “old school” closed approach and restrictive licensing on the FDX API. This is a common approach of old school industry standards, but for modern web and HTTP APIs, it is not normal—-something I’ll write about separately. I am going to do a little more work on the Mastercard Developer Hub for FDX APIs blueprint, and spend more time learning about the design of the FDX APIs (via Mastercard’s implementation). I am going to give the same attention to FHIR, and a handful of other industry API standards out there, until I have robust blueprints and a strong understanding of these API standards. There is a HUGE opportunity to standardize and share patterns across industry standards–think FAPI but for other industries, and consent APIs, but for other types of personal data.
