What Banking's Open-Data Decade Proves About Transportation's Near-Future
For decades, the financial services world operated on a familiar technology model. Institutions invested heavily in proprietary systems, data remained largely tied to the platforms that generated it, and interoperability needs were generally addressed via costly, time-consuming, consultant-led integration projects that rarely resulted in desired functionality or business outcomes. As imperfect as that model was, it wasn't irrational because it held up against the data security and compliance demands of the day. But as banking became digital banking around the 2013-14 timeframe, the cost and complexity of connecting those closed systems became increasingly difficult to sustain. Over the past decade, banks have responded by steadily separating control of the data from control of the systems through which that data flows. The benefits have been many and well documented.
Transportation is approaching a similar transitional crossroads, pun intended. Agencies at the state and local level are managing a rapidly expanding mix of connected infrastructure, roadside sensors, video, edge computing, cloud platforms, connected vehicles, and AI-enabled applications, usually run in operational environments designed for a much less-connected era. As the volume and value of transportation data grows, so do the costs and complexity of integrating it repeatedly through proprietary vendor-dictated architectures. The experience of the banking and financial services space offers useful precedent for what happens when an industry reaches a point where data has become an asset of increasing value: interoperability and openness begin to move from desirable technical features to practical requirements for continued innovation. Remember when you couldn't see your checking balance from one bank alongside your investments at another? That's one small but powerful example of innovation achieved through open data standards and practices.
That started roughly a decade ago and occurred for a reason worth studying outside of finance. Banks realized that owning the data layer and controlling access to it were not the same thing: A bank that opens its data through a common, well-governed interface doesn't lose that data. On the contrary, it gains every product built on top of the data interface, plus the buy-in of customers who can finally manage their financial lives semi-seamlessly across institutions and product types. Openness turned out to be the moat, not the leak.
Capital One offers a great example of a regulated financial institution embracing open data and open-source code as a strategic imperative. In 2016, the bank released Cloud Custodian, a rules engine for cloud governance, as an open-source project. Again, a bank published the tool it uses to police its own infrastructure for anyone to inspect, fork, and improve (AWSInsider). This would have been unimaginable just a few years earlier, sharing a trade secret with a competitor. Capital One later did the same with DataProfiler, an open-source Python library its Applied Research team built to automatically identify schema, statistics, and sensitive data across messy, heterogeneous datasets (Capital One). Neither project was a marketing gesture. Both resulted in tools the bank needed to run itself safely… published on the theory that the industry is better off when the governance layer is shared and inspectable rather than proprietary and sold via subscription.
The concept organically scaled beyond CapOne and other individual banks, evolving to promote shared infrastructure. In 2018, the Financial Data Exchange — a non-profit, royalty-free standards body — was founded to ensure secure and transparent user-permissioned financial data sharing. The body now counts more than 180 institutional members and has moved over 100 million consumer accounts onto one common API for permissioned data sharing (FDX, Ozone API). Nobody forced these competing banks, fintechs, and data aggregators to agree on one common schema. They did it because a few forward-thinkers realized that every institution was about to build its own version of the same interface – potentially poorly and at its own expense – and a shared standard was cheaper than many different attempts at the same thing. That made adoption of an "API-first" posture essentially an industry-level decision, not just a well-conceived engineering pattern unique to a few teams inside a few institutions. Sharing via open, standardized schema and public APIs allowed the cost-to-serve to drop for all.
Then, regulation was proposed following creation of the new standard. The CFPB's Personal Financial Data Rights rule, finalized under Section 1033 of Dodd-Frank in October 2024, attempted to codify a consumer's right to their own financial data in a standardized, machine-readable format (Congress.gov CRS). That rule is now enjoined and is being reconsidered, its future uncertain (Open Banking Tracker) because this isn't a technology problem after all, it's a people agreeing problem.
But please note what didn't get mired in the regulatory bog: FDX kept shipping API versions, bank teams kept building to it, and the open-source market kept developing on the schema independent of the status of the legal mandate. It was just a better answer, laws or no. Regulators believed rules would ensure safe interoperability for bank data. Instead, the industry built the interoperability layer, deployed it, and is using it successfully around a shared, open standard today. Meanwhile the regulation is still stalled. The sequencing here is the real lesson, independent of how the rulemaking efforts end.
Similarly, and as a third working example from the finance world, cross-border payments have traveled their own version of this road. Open data standards won the day here as well. Today, ISO 20022 is a global, open, non-proprietary standard for financial messaging. It's not owned by any single processor or bank but rather maintained through a shared industry-wide governance process. The financial industry has now run this experiment three separate times, at three different layers (cloud tooling, consumer data access, and payment messaging) and settled on the same answer each time: The shared, open, relatively boring standard tends to win out over the proprietary, expensive alternative… once enough industry stakeholders have had the chance to talk about options together.
With thanks to the banks for their guidance, we now see that the transportation infrastructure space hasn't had its FDX moment just yet. Today's roads, signals, sensors, and connected vehicles generate enormous and rapidly growing volumes of operational data — and almost none of it moves through anything resembling a common, open, versioned schema. Every agency's data still speaks a dialect defined by whichever vendor won that decade's procurement exercise. And that's the state consumer banking data was in before FDX existed; terabytes of data, potential insights and intelligence ready to be innovated on, yet no shared grammar for anyone outside the vendor relationship to use it.
Pressure is mounting in transportation and ITS circles thanks to the proliferation of AI. Today's intelligent systems are being trained on many various types of structured data and there are eyes on the pace of resulting innovation. The punchline is this: The institutions (public or private) that show up with clean, well-governed data defined by shared, open schema will shape how those systems represent the domain for years. Finance had a decade to conceive of the need for FDX. Transportation does not have a decade. ITS funding cycles and the innovation they support are all advancing on the same shot clock. Stakeholders offering a fluent, open, readily available schema could see their approach become the default, as FDX did. Remember FDX didn't win the day because of slanted rules or a regulatory capture regime. They won because of the realization that building to one open standard is cheaper, easier, and more common sense than building to no open standard.
This same choice is available to the transportation space now through Vikasa. DOT and IOO stakeholders can embrace the opportunity to secure access to the innovation and cost-advantages seen in other industries … or run the risk that industry hardware and software hegemons thwart the energy of the moment because existing commercial models create economic incentives to preserve proprietary interfaces and customer dependence.
Licensed under Apache 2.0, OpenITS provides canonical transportation data schemas governed publicly for anyone to download, inspect, fork, and build against on GitHub.
So, is this the beginning of the "the FDX moment" the transportation hasn't yet had? The banks didn't wait for perfect consensus or finished regulation to start building the standard. They just started building via open, modern approaches and let adoption do the rest. And that's the punchline for transportation technologists, strategists and operators everywhere. Look up OpenITS. Borrow. Build. Post. That's how the standard becomes The Standard … as proven on Wall Street.
