suadelabs/fire

Financial Regulation (FIRE) Data Standard

layout	title
readme	Home

Financial Regulatory (FIRE) Data Standard

---

What is the FIRE data standard?

The Financial Regulatory Data Standard (FIRE) defines a common specification for the transmission of granular data between regulatory systems in finance. Regulatory data refers to the data that underlies regulatory submissions, requirements, calculations 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 the financial sector (think Hadoop, Cassandra, ActiveMQ).

The FIRE data standard is supported by the European Commission, the Open Data Institute and the Open Data Incubator for Europe via the Horizon 2020 funding programme.

---

Please see the contributing guidelines and guiding principles if you would like to contribute to this project.

Random FIRE Data Generator

Included is a random data generator which will generate data in line with the FIRE schema, but not necessarily realistic. (eg. You might get a loan with a balance of 10 but accrued interest of 1 million)

Testing

You can run tests locally via ./run_tests.sh or view the CI test results here

---

fire's Issues

Enhance securitisation attributes

excess_spread_type	no excess spread
	fixed - trapped
	fixed – use or lose
	variable – trapped
	variable - use or lose
amortisation_system	Sequential amortisation
	Pro-rata amortisation
	Pro-rata amortisation changing to sequential amortisation. Compliant with STS criteria for on-balance sheet securitisations (Article 26c (5) of Regulation (EU) 2017/2402).
	Pro-rata amortisation changing to sequential amortisation. Compliant with STS criteria for non-ABCP transactions (Guidelines on STS criteria for non-ABCP transactions and Article 21 (5) of Regulation (EU) 2017/2402
	Pro-rata amortisation changing to sequential amortisation. Not compliant
	Other amortisation system
retention_type	Vertical slice (securitisation positions): “retention of no less than 5 % of the nominal value of each of the tranches sold or transferred to the investors”
	V - Vertical slice (securitised exposures): retention of no less than 5 % of the credit risk of each of the securitised exposures, if the credit risk thus retained with respect to such securitised exposures always ranks pari passu with, or is subordinated to, the credit risk that has been securitised with respect to those same exposures;B - Revolving exposures: ”in the case of securitisations of revolving exposures, retention of the originator’s interest of no less than 5 % of the nominal value of the securitised exposures”;
	C- On-balance sheet: “retention of randomly selected exposures, equivalent to no less than 5 % of the nominal amount of the securitised exposures, where such exposures would otherwise have been securitised in the securitisation, provided that the number of potentially securitised exposures is no less than 100 at origination”;
	D- First loss: “retention of the first loss tranche and, if necessary, other tranches having the same or a more severe risk profile than those transferred or sold to investors and not maturing any earlier than those transferred or sold to investors, so that the retention equals in total no less than 5 % of the nominal value of the securitised exposures”;
	E – Exempted. This code shall be reported for those securitisations affected by the application of Article 6(6) of Regulation (EU) 2017/2402;
retention_percentage
type	Abs_CC_rec
	Abs_SME_retail
	Abs_wholesale_loans
	Abs_SME_corporate
	ABS_corporate
	Abs_lease
	Abs_trade_rec
	Abs_wholesale_other
clean_up_call
seniority	Senior
	Mezzanine
	First_loss

Test links in documentation are still alive

O Canada, we expand our codes for thee

Add schema test for property documentation

Doc files specify which schemas each property can be found in at the top. Let's add a test to enforce it!

Should the schemas include an ID attribute?

https://github.com/json-schema/json-schema/wiki/The-id-keyword

Create test to scan for fields without descriptions

There are some fields missing descriptions - let's automate the process of finding them. (TravisCI)

Add documentation to loan_transaction type

Definitions

• advance
• capital_repayment
• capitalisation
• due
• further_advance
• interest
• interest_repayment
• other
• received
• sale
• write_off

https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/crd-iv/mlar-notes-may-2022.pdf
https://www.bankofengland.co.uk/prudential-regulation/publication/2018/fca-and-pra-changes-to-mortgage-reporting-requirements
https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/policy-statement/2019/ps2219.pdf

Add a test to ensure that examples comply with the schema

There should be a test catching cases where example refers an invalid attribute, or an invalid value for a given attribute.

For instance, this example: https://github.com/SuadeLabs/fire/blob/master/examples/collateral_variation_margin_cash_posted.json

One of the agreements has credit_support_type: "other", but "other" is not a valid credit_support_type according to the schema. This should have been picked up by a test when the example was added (or the schema changed).

Do we need an encumbrance_fv field?

For fair value amount of encumbrance in addition to the carrying/accounting amount used for the currency encumbrance_amount?

add frist_arrears_date

Reporting LEI column should have "min:20" and "max:20" in all schemas (now only in loan).

The only schema that has the "minLength" and "maxLength" fields in the Reporting LEI column is the "Loan" schema. This should be in all schemas as the LEI is always 20 characters.

Fire validator should be more verbose about what schemas are satisfied

Most of the fields are optional, and as such, the validator turns green quite often - even if the data isn't exactly correct. It would be wonderful if the validator communicated if the data pasted was valid for "loans", "customers", etc.

Should we embed versioning info in the schemas?

For example, via "self-describing" the versions:

http://snowplowanalytics.com/blog/2014/05/15/introducing-self-describing-jsons/

Add collateralisation_ratio to security schema

Sample data would be great

Example JSON blobs of Loans/Accounts/Customer etc would be helpful for people wanting to become FIRE compatible.

Add versioning to schemas

qmdb

Add single collateral pool and OCIR

Add single_collateral_pool as a subtype of collateral, and add ocir as a security type

FIRE <> EMIR mapping

Create a sample mapping from FIRE to EMIR RTS fields

Update FIRE docs for bond future

The start_date on a bond future should be > reporting date.

Move FIRE website to github

Update curve schema reference property enum list

Updating curve schema reference property to align with the requirements of AMM C69.00

Grammar Error in README.md

Grammar Error

Add Guarantor PD and LGD to Guarantor Schema

fix repo and rev repo examples

"type" field is wrongly set to cash for cash legs of SFTs, it should be set to the type of the underlying security

Migrate country codes to ISO_3166-2 standard

Some regulators might consider relevant to have the country information disclosed by regions, so it could be interesting to start handling that by using ISO_3166-2 standard
https://en.wikipedia.org/wiki/ISO_3166-2

XBRL and FIRE

With the more popular and widely adopted data exchange format standards such as XBRL, can this format be translated into XBRL format to form a formal verification / gap analysis of compliance requirements against the reported data?

Are there any architecture diagrams of how FIRE data exchange format for regulatory data can be implemented or commonly should fit in an information infrastructure?

Auto-generate release notes

Create a transaction base schema

Account transaction and loan transaction schemas are very similar.
Create a base transaction schema with the common fields and extend them with properties specific to each account/loan transaction.

Adjustments: contribution_amount and contributon_text are not exclusive

In particular, this is valid under a compliant JSON-schema validator, so long as currency_code is not present:

{"id": "a", "contribution_amount": 123, "contribution_text": "hi", ....}

This is because the oneOf logic here https://github.com/SuadeLabs/fire/blob/master/v1-dev/adjustment.json#L62 is an exclusive or implemented like

(a or b) and not (a and b)

Solution

We should change this to

"oneOf": [
   {"required": ["id", "date", "report_type", "row", "col", "contribution_amount"]},
   {"required": ["id", "date", "report_type", "row", "col", "contribution_text"]}
 ],
 "dependencies": {
      "contribution_amount": ["currency_code"]
}

this would make these fields exclusive and would mean that if contribution_amount is populated, currency_code must be too.

Create a travis CI job for tests

• jsonlint
• jsonschemalint
• spelling?
• ??

Add expanded deferred_tax to account purposes

Add new account purposes to distinguish deferred tax that is deductible/non-deductible, relies on future profitability and/or is due to temporary differences

add encumbered loan example

adding type string to enum fields

Fixing the mess

Create an examples schema

The examples in /examples/ should be rigorously tested and validated against a json schema.

add hybrid contracts to security schema

restore curve values

Should there be a "BankData" base object?

All of the schemas have a "id" and "date" field. All the schemas (except batch) inherit from "object". If we instead create a base schema called "BankData" that has id/date, then all child schemas can inherit from that and get the fields automatically.

Broken link in documentation

In CONTRIBUTING.md the link to the community guidelines is https://suade.org/fire/guidelines/ which leads to a 404 page. After a bit of searching, I re-found the guidelines at https://suade.org/fire/guidelines.html. This is live on the website as well

Create a short introduction to schemas "one-pager"

Aimed at less technically savvy people - explain how to read json schemas and what it all means.