FIRE Manifesto


What is the FIRE data format?

The Financial Regulatory data format defines a common specification for granular regulatory data. Regulatory data refers to the data that underlies regulatory submissions and is used for policy, monitoring and supervision purposes.

The FIRE data schemas and code samples are licensed under the Apache 2.0 License which has been chosen for being open, permissive and already widely accepted within financial sector (think Hadoop, Cassandra, ActiveMQ).

The FIRE data format is supported by the European Commission, the Open Data Institute and the Open Data Incubator for Europe.

Why a common format?

While every financial institution is different in its own way, regulations require every firm to collect certain data points with specific definitions. As these requirements have evolved and developed over time, no comprehensive documentation exists for what granular data needs to be collected. So if you want to start a new bank and issue a mortgage, there is no readily accessible technical documentation for all the fields you need to record for a mortgage. As such, every firm collects and stores this data in a different format with different definitions (or worse, relies on their vendor to decide for them). This makes data exchange between firms, firms and regulators and internal IT systems a manual and error-prone ETL process.

This is the primary reason, in our opinion, that financial institutions face enormous challenges for consistency, quality and transmission of data between systems as each system and each bank has a different idea of what a mortgage should look like from a data perspective.

While we cannot accomodate every nuance of a product that a firm might want to collect, we can be certain (due to regulatory needs) of the data a firm must have. These required data fields are therefore the basis of FIRE data.

How does this fit with other FinTech data initiatives?

Looking at the Open Data Institute’s Data Spectrum, much work is being done at the open end of the spectrum to define the format and content of data that is presented to consumers. Projects like the OpenBankProject for example. Ultimately however, this is not the data format banks use internally and not the data that regulators monitor to ensure financial stability. The goal of the FIRE project is therefore targeted at the less visible part of the data spectrum and focuses on a data exchange format rather than the data itself.

Summary of challenges addressed by a common format

Benefits of a common format are immense:

  • Internally it allows for proper control and governance of key data points and a comprehensive understanding of core regulatory fields and supplemental data fields that are proprietary to a firm. Simply converting to the FIRE format has allowed many firms to fill gaps in their regulatory data requirements.
  • Externally, it offers regulators comparability of transaction data (not just top-line information), easy exchange of risk and product information amongst firms as well as well-defined integration of systems that use this data.

Why now?

The financial crisis brought into focus both the global scale of the financial industry as well as the fragility of such an interconnected network without transparency. If a common data format for mortgages had existed in 2007, banks could have seen growing risks in mortgage-backed securities more readily instead of just relying on top-level ratings. Harmonising the data format is the first step towards preventing the next financial crisis. Furthermore, the crisis and regulatory weight has left banks bordering on profitability, no longer having the deep pockets and resources to support complex, bespoke, internal systems. Standardisation of non-core functions like reporting and data storage will help reduce costs dramatically across the industry.


Standardising the data format for financial products is certainly a massive task, but it is a communal problem that all global financial institutions share (at least for the regulated world). Therefore, we are looking for contributors of all types, developers, lawyers, accountants, fintech companies, consultants, regulators, traders, structurers, back office, settlement, operations, reg policy, finance, risk etc. If you do contribute however, please respect other contributors and keep in mind our community guidelines.

You do not have to be a developer to help create a data standard!

Sign up at