Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
A move to machine-executable digital regulatory reporting is closely linked with the need for data standards. There are significant benefits in the medium- to long-term for financial institutions and authorities to move towards a digital reporting framework, for the reasons highlighted in this background section.
Nevertheless, the initial investment and costs needed to achieve this outcome can steer decisions based on business incentives and risk appetite. While data standards initiatives would ultimately benefit from – and require – financial institutions and authorities to adopt a greenfield approach, the perceived scale of such an exercise could also deter stakeholders from committing to its implementation.
We propose that in the absence of global or national data standards, alternative options could be explored as a first step to bringing stakeholders closer to a common understanding of data needs. These options can include:
Bringing together authorities that have a mandate to collect data, to see if there are similarities or commonalities in the type of data being collected.
Engaging with industry on their use of data models and taxonomies for that specific product to explore wider extensibility.
Establishing small working-level projects using a narrowly scoped and specific use case and agreeing common data attributes and their definitions “in principle”.
Exploring ways in which the requirements for the reporting of those data can be published in programming languages.
Despite the varied and sometimes bespoke nature of some mortgage products, we found that mortgage transaction data and the respective reporting requirements aligned around three main components:
The Loan
The Borrower
The Collateral
Based on these components, as well as taking into consideration the type of data that is needed for both authorities for supervisory purposes, a minimum common set of requirements was developed for the collection of data for retail mortgages. Legislative or regulatory requirements that were jurisdiction-specific were excluded for this exercise.
Project Ellipse explores how stakeholders can gain an understanding of the requirements needed to shift to digital reporting, without needing to commit and invest significant resources upfront. For Project Ellipse, we adopted the following approach to explore the concept of cross-border digital reporting:
Taking two authorities from different jurisdictions, to see if a common understanding of data reporting needs could be achieved cross-border and between two different reporting regimes. In this POC, the authorities were the BoE and the MAS.
Working on a narrowly defined and small use case for a regulated product that was common to both authorities. We used a subset of reporting requirements for retail mortgage loans.
Using an existing industry data model to test its extensibility to a different product domain to see if the components and attributes could be repurposed. We tested the Common Domain Model (CDM) developed by the ISDA, which is an open-source machine executable data model.
Data standards, taxonomies and data models are integral for digital reporting and for enabling data-driven analytics. To demonstrate that the utility of common data standards and models extends beyond nationally specific contexts, Project Ellipse explores whether authorities in different jurisdictions could also come to a common understanding of data for regulatory reporting purposes. This is because reporting platforms built on common data models offer the possibility that global financial reporting entities can fulfil different cross-border reporting obligations using a common input layer. This could reduce compliance burdens placed on those financial institutions to respond to template-based regulatory reporting requests from different supervisory regimes. It could also enable home and host supervisors of these global reporting entities to compare exposures in a more consistent and transparent way.
Project Ellipse is a proof of concept (POC) launched by the Bank for International Settlements Innovation Hub (BISIH) to explore how supervision could become insights-based and data-driven using an integrated regulatory data and analytics platform.
Regulatory authorities, as the ultimate end users of the platform, would be able to digitally extract, query and analyse a large quantity of data from diverse sources. These data could then be relevant to current events in real time and visible via dashboards, informing them of early supervisory actions that may need to be taken.
The Bank for International Settlements Innovation Hub Singapore Centre is partnering with the Monetary Authority of Singapore (MAS) to deliver a prototype and reference implementation of an integrated regulatory data and analytics platform. Project Ellipse is motivated by how supervisors can better harness data and technology to help them identify and assess emerging risks in real time to inform them of early supervisory actions that may need to be taken.
Project Ellipse is being developed in two phases. This documentation contains information on the background for this project, and details on the POC for a cross-border data model explored in Phase 1. Further information on Phase 2 will be provided by the end of 2021 and towards the end of Q1 2022.
The project is being developed in the following phases.
Supervisors today rely heavily on regulatory reporting to inform them of potential risks that may be forming in regulated entities, which can have broader implications for the financial system. However, there are challenges with the information that supervisors receive from regulatory reports, such as the ones listed below.
The challenge is how supervisors can form an accurate picture of exposures and have predictive insights into emerging risks using these data sets. Project Ellipse therefore explores how supervisors can better identify and assess emerging risks in real time to inform them of early supervisory actions that may need to be taken.
To meet these challenges in the digital age, authorities could benefit from “on demand” access to timely and integrated sources of data to help support and inform their supervisory assessments. Several possible solutions are therefore explored in this project.
Data-driven insights start with large quantities of structured granular data. A key component of an Ellipse-type platform that would enable supervisors to be data-driven is a system for the digitally enabled collection and processing of granular and standardised data. This means that those data are:
Consistently understood by all stakeholders
Can be repurposed for different use cases
Represented in such a way that allow programmable code to reference those data to generate the reporting of regulatory metrics.
To find a common understanding of data collected for regulatory purposes across reporting regimes, the Project Ellipse team used the reporting requirements for retail mortgages in the UK and Singapore.
Retail mortgages were selected for this exercise because while the collection of this data is common across authorities globally, the templates and formats used to collect these data are highly heterogenous. To illustrate, Ellipse based its modelling exercise on the following two regulatory reporting requirements in the UK and Singapore:
The former is an example of reporting requirements being presented in a template, while the latter is an example of requirements being integrated within prudential instruments.
The aim of the initial exercise was to take these respective reporting requirements, with a view to determining whether common baseline requirements could be established. This required a common understanding of the rationale for the data collection, the type of information that is needed for supervisory purposes and what information was “optional”.
Taking the common baseline set of requirements, we were able to drill down into the three main components further to reflect what we considered the key attributes of retail mortgages that were relevant for this POC.
These data attributes were also intended to be used to calculate or aggregate supervisory metrics. For example, "loan size" and "value of property" would be the key inputs to derive the loan-to-value measure. Other types of aggregation would also be enabled, such as loan-to-income, total loans issued by postcode or total loans issued by purpose (eg owner-occupied or buy-to-let investment).
Agreement on common data attributes also necessitates an agreement on their definitions. During the process of identifying attributes for retail mortgages, definitions were sourced from either the respective jurisdictional frameworks or third-party sources where existing definitions did not meet the needs of the respective reporting requirements.
These definitions are solely to inform the data attributes of the POC and are not reflective of the actual prescribed definitions found in either reporting regime. However, it is intended to illustrate the exercise of agreeing to a definition “in principle” for the modelled attributes, as well as to highlight the importance in a cross-border context of definitions that are applicable in other jurisdictions for similar products. Converging on a common understanding of products and their definitions is an important step towards normalising their use in a standardised manner.
A number of regulatory authorities have been exploring different ways in which to replace template-based, aggregated regulatory reporting with granular data and digital regulatory reporting []. The vision of regulatory reporting using granular data removes the need for multiple templates, allowing supervisors the opportunity to constantly re-purpose common data points for different analytical use cases.
However, granular reporting requires a common understanding by authorities and financial institutions of what those data are, so that financial institutions can map their operational data to a common “input” before the required reporting can be generated. Important initiatives around data standards, taxonomies and data models are being developed for this purpose []. However, data standardisation more generally remains nascent globally.
UK:
Singapore:
Phase
Description
Phase 1 January to September 2021
The first phase explores the potential process efficiencies gained by both authorities and financial institutions if granular data could be mapped to a common cross-border data model, thereby moving away from fixed templates. For authorities, having access to granular data also increases the volume of information needed to enable the use of advanced analytics. In Phase 1, the BISIH, the MAS, the Bank of England (BoE) and the International Swaps and Derivatives Association (ISDA) collaborated to explore the concept of cross-border digital regulatory reporting, using a machine executable data model.
Phase 2
August to February 2022
In Phase 2, the project explores the use of advanced analytics such as artificial intelligence (AI) and machine learning (ML) to mine unstructured sources of data and highlight correlations between current events and supervisory metrics. Insights extracted from the mined data would be displayed as early warnings for supervisory attention via a dashboard.
Completion
March 2022
The project will develop a prototype and demonstrate a reference implementation of an integrated data and analytics platform for central banks and regulatory authorities. The Ellipse platform will be built using an open-source data model and technology stack that can be shared with regulatory authorities and financial institutions globally to achieve this purpose. Each phase of the work will show components of the integrated platform, with a view to enabling stakeholders to “plug and play” these components within their own environments.
Attribute | Ellipse POC definition |
LOAN |
Transaction ID | Unique identifier (ID) for each loan: the loan ID should not change through the life of the transaction, if the original loan ID cannot be maintained in future in this field enter the original ID followed by the new ID |
Purpose | The reason for taking the mortgage loan. Buy a first home; Buy another home; Re-mortgage from another lender |
Loan Size | The original balance when the mortgage was completed. Amount of loan approved (and currency of loan) - (in UK also including fees + charges). In the case of loans where the amount advanced is less than the total amount of the loan which the firm has agreed to lend, this should be the amount of the committed advance (including any committed drawing facilities). |
Main/First Borrower ID | Unique identifier (ID) per borrower (not showing the real name) to identify the point of contact amongst the borrowers or the largest borrower (in terms of liabilities) in a group of borrowers. Should not change over the life of the transaction. If more than one borrower list the Borrower ID's with comma delimitation with primary borrower first. |
Date mortgage matures based on contract date | The date the loan contract is due to mature if it goes to full term. (This can then be used to calculate the remaining loan tenure at any point in time.) |
Initial rate | The rate of interest reported should be the initial gross nominal rate charged on the loan and should take into account any discount being provided. |
Reversionary interest rate | Type of interest rate at end of initial incentivised rate period. Could be fixed rate, discount, capped rate, standard variable rate, base rate tracker, reference rate tracker, other tracker, other or not applicable. |
Date of first drawdown | Date on which the initial tranche or complete amount of the mortgage loan is transferred from the lender to the borrower or their agent. |
COLLATERAL |
Collateral ID | Unique identifier per property to enable properties with multiple loans in the pool to be identified (e.g. further advances / second lines are shown as separate entries). |
Country where Collateral Property is Located | The ISO code of the country where the land/ property which is subject to mortgage is located. |
Property Type | For POC limited to Private residential which refers to privately owned property for occupation of at least 40% as a dwelling by the borrower(s) and/or dependent(s). |
Dwelling Type | One option from list below per mortgaged property. A dwelling is a self-contained room or suite of rooms, including cooking and bathing facilities, intended for long-term residential use. A dwelling is private (not generally accessible by the public) and is contained within a building that is an immobile structure. A dwelling may comprise part of a building or the whole of a building. Regardless of whether they are self-contained or not, rooms within buildings offering institutional care (e.g. hospitals) or temporary accommodation (e.g. hotels, motels or hostels) are not defined as dwellings. |
| A single storey dwelling, usually detached. |
| A standalone residential structure of more than one storey that does not share any outside walls with another residential property. |
| A residential dwelling of more than one story in height attached to another building or dwelling by one common party wall. |
| A dwelling of more than one storey attached to another house on two sides forming part of a row of similar houses each with its own frontage to a road. |
| An apartment/ flat /condominium is a separate and self-contained premise constructed or adapted for use for residential purposes and forming part of a building from some other part of which it is divided horizontally. Flats have to be contained within a dwelling with at least two storeys. These dwellings do not have their own private grounds and usually share a common entrance foyer or stairwell. Does not include duplexes, townhouses or a detached residence that includes a flat (such as a granny flat) on the same property. Also includes Maisonettes - in the case of the UK, which refer to a set of rooms for living in typically on two storeys as part of a larger building with a separate entrance from rest of the building. Can be one level or split level. include both purpose built and converted buildings. |
| Any other type of residential dwelling property. |
Value of Property | The market value of the property which is subject to the mortgage. The value reported should be based on the surveyor’s valuation, a valuation index, or other method that the product provider used to determine the market value. [In the case of staged construction or self build schemes, value means ‘expected final value of property at the time the lending decision is made’.] |
Purchase Price of Property | The purchase price of the land/buildings which are the subject of the mortgage as stated on the mortgage application. |
Postal Code | Format of this will be country specific. [In UK, for new build/self build properties only, firms may report only the first half of the postcode, e.g. XY45, if the full postcode has not yet been assigned. For all other properties, the full postcode of the property must be reported, e.g. XY45 6XX. ] |
BORROWER |
Borrower ID | Unique identifier (ID) per borrower (not showing the real name) - to enable borrowers with multiple loans in the pool to be identified (e.g. further advances / second liens are shown as separate entries). Should not change over the life of the transaction. If more than one borrower list the Borrower ID's comma delimited with primary borrower first. |
Borrower Type | An individual or natural person (may be more than 1) - in UK can also have a trustee but this is out of scope for the POC. An entity/firm/corporate is also out of scope for the POC. |
Employment Status | One option from list below per individual. Where the borrower has more than one employment status, report status that makes up largest portion of verified income. |
| An individual who works under an employment contract. They are usually required to work regularly, required to do a minimum number of hours and expect to be paid for time worked. A manager or supervisor is responsible for their workload, defining when a piece of work should be finished and how it should be done. Work is done at the business's premises or at an address specified by the business. The business provides the materials, tools and equipment for their work. |
| An individual is self-employed if they run their business for themselves and take responsibility for its success or failure. They can decide what work they do and when, where and how to do it and can work for more than one client. |
| An individual who has reach the official retirement age or other specified age and is usually no longer undertaking paid employment. |
| Examples include company directors. |
Income Type | A borrower may have income of more than one type. (As from the list below) |
| Gross annual income from employment before tax or other deductions. This should be evidenced, either document based (e.g. payslips, bank statements or tax returns) or derived through the use of automated systems. |
| Gross annual income from self-employment before tax or other deductions. this should be evidenced, either document based (e.g. bank statements or tax returns) or derived through the use of automated systems. |
| Income from sources other than employment such as pensions or investments. |
Income Amount | "Gross monthly income, in relation to a Borrower, shall be the aggregate of: |
(a) in the case where the Borrower has a fixed monthly income only, his monthly income (in the case of SG, excluding any contributions made to the Central Provident Fund account of the Borrower by the Borrower’s employer, where applicable) at the time of applying for a credit facility or a e-financing |
(b) in the case where the Borrower has a variable income only, such as commission, bonus or allowance from his employer |
(i) the average of the monthly variable income earned in the preceding 12 months |
(ii) the employment income reflected in the latest available assessment of taxable income from the tax authority, at the time of applying for a credit facility or a re-financing |
(c) in the case where the Borrower has a fixed and variable monthly income. |
(i) the aggregate of his fixed monthly income as determined in accordance with sub-paragraph (a) above and his variable monthly income as determined in accordance with sub-paragraph (b)(ii) above; or |
(ii) the aggregate of his fixed employment income and his variable employment income reflected in the latest available assessment at the time of applying for a credit facility or a re-financing |
(d) the monthly rental income received by the Borrower (in the case of SG), if any; and |
(e) the value of the eligible financial assets of the Borrower (in the case of SG), if any. |
Currency of denomination | GBP = United Kingdom Pound; EUR = Euro; USD = US dollars; JPY = Japanese Yen; OTH = other. If more than one applies, report the currency that applies to the largest proportion of the mortgage. |
Income Frequency | The frequency in which gross basic pay from employment (whether from one or more jobs), gross income from self-employment insurance or pensions, and state benefits is paid out. |
Type of debt | Report only where the borrower is consolidating debt into the new mortgage. Type of debt shall be anything where the borrower is obliged to make payments in the future. |
Debt Servicing Amount | Refers to the amount of outflows per period that the borrower is subject too at the point of applying for a credit facility or a re-financing. |
Frequency of Payments | The frequency in which the bank is deducting money from your provided bank account to serve your mortgage loan. |
Project Ellipse explores the feasibility of cross-border digital reporting. This POC is intended as a first step towards bringing authorities and stakeholders closer to a common understanding of data that is collected by authorities globally.
Our exploration confirms that:
Regulatory reporting requirements can be expressed in unambiguous machine-readable logical reporting instructions underpinned by a consistent data model;
Technical standardised programmatic specifications of the steps for generating regulatory reports can be published alongside regulation and ensure clear understanding at the most granular level of the expected data;
Executable libraries can be automatically generated and published alongside regulations to assist accelerated implementation;
If a common data standard was agreed to and implemented, financial institutions may no longer need to interpret reporting instructions and submit aggregated data by use case; and
With additional logical instruction based on the same data model, supervisors may also be able to automatically query the underlying transaction data and generate regulatory metrics referencing that standardised data.
Phase 1 of our project illustrates the potential for process efficiencies that may be gained when adopting machine executable reporting using common data models. It could also increase the volume of granular data available to supervisors, which is needed to enable the use of advanced analytics. Further exploration between regulatory authorities would be needed to validate these findings and to see whether the exercise could be extended to other reporting use cases.
Building on this first use case, Phase 2 will explore the integration of granular data sets with unstructured data, using AI and ML to extract insights from these data sources to highlight correlations between current events and supervisory metrics. Insights extracted from the mined data would be displayed as early warnings for supervisory attention via dashboards.
Challenge
Description
Template-Based, Aggregated
Regulatory requirements are often template-based and ask for aggregate data, meaning that data sets are fixed to a use case and hence the data received cannot be easily reused for other purposes. New reporting requirements are needed each time additional or ad hoc information is needed.
Data is inconsistently described
Reporting data is often sourced from legacy data systems within reporting firms that are not always integrated. This often results in heterogeneity of data for any given product or transaction – both within a bank and across different banks – as systems will describe these data differently.
Regulatory reports are submitted to supervisors from reporting entities on an infrequent basis (e.g every month or quarter). At times of heightened risk, the need for up-to-date data increases but given the static nature of regulatory reports, supervisors may not have the timeliest data to make informed judgments.
Information contained in regulatory reports are often linked with other types of information that may point to emerging risks, but these sources of information are not connected. For instance, information sourced from market data and news are often the first indications of emerging risks but it is difficult for supervisors to scan through the vast volumes of market and news data to assess which point to a need to take early action.
Solutions | Descriptions |
The collection of granular data from reporting entities could replace the need for authorities to request information using templates. It could also enable authorities to reuse those data for different use cases. Supervisory metrics could also be derived using granular data, as opposed to requiring reporting entities to aggregate the required data prior to submission. |
| Differences in the description of data for similar products and transactions across banks can be addressed using data standards and common data models. Granular reporting requires a common understanding by authorities and financial institutions of what those data are, so that financial institutions can map their operational data to a common “input” before the required data can be reported. Supervisory metrics could then be derived using programmable rules that reference machine readable and machine executable common data models. |
| Real-time insights using advanced analytics could be derived from large volumes of unstructured data that would supplement the granular reporting available. This would provide supervisors with additional indicators and early warnings of at-risk exposures of reporting entities. |
| Integrating granular data from reporting entities with other sources of unstructured information such as news and market data onto the same platform means supervisors would not have to spend time manually scanning for information. Advanced analytics such as artificial intelligence and machine learning could be used to make risk correlations and analyse sentiment, alerting supervisors in real time of issues that may need further investigation. |
Digital reporting requires data attributes to be represented in a way that allows programmable functional logic code to reference and generate the reporting of regulatory metrics. This is otherwise referred to as reporting being “machine readable and executable”. Project Ellipse sought to explore whether existing industry data standardisation initiatives could be re-purposed for different use cases, such as retail mortgages. Of particular interest were those initiatives that were open-sourced and geared towards being machine readable and executable.
For these reasons, we modelled the POC mortgage attributes using the CDM. Testing the CDM’s use and extensibility for other product domains such as mortgage loans was key to the POC, as globally applicable common data models that can be used across products could minimise the number of data models in use by financial institutions and reduce mapping burden. In addition, as the CDM is open-sourced, this allows the model to be more widely accessible for testing within existing environments.
To achieve standardisation across products and asset classes, the CDM identifies logical components that fulfil the same function and normalises them, even when those components may be named and treated differently in the context of their respective markets. We followed the CDM design principle of normalising concepts such as quantity, price and party in the representation of financial transactions.
The CDM identifies that, regardless of the asset class or product type, a financial transaction always involves two counterparties trading (ie buying or selling) a certain financial product in a specific quantity and at a specific price. This approach means that a single logical concept such as quantity can represent concepts that may be named and captured differently across markets: eg notional or principal amount etc.
Following this approach, we took the modular components that exist in the CDM and reused concepts such as product, loan, price, collateral and party to reflect the mortgage attributes that characterised loan, borrower and collateral. We also extended the model to reflect attributes that were specific to the POC around collateral (eg property) or the credit profile of the borrower (eg credit details).
The following section further describes the data attributes of the CDM Mortgage Schema that seeks to follow the data structure of the Financial Products Markup Language (FpML). Selected examples of the CDM data attribute definitions are used as illustrations to help explain various dimensions of the model, and include data samples and code snippets to help demonstrate the CDM structure, where applicable.
Contract details: defines specific attributes that relate to contractual details of a trade; it describes the key documentation and party contractual information of the model.
The Documentation Identification
set of data attributes represents the legal document(s) meta data that governs a trade and associated contractual product terms, either as a reference to such documents when specified as part of the CDM, or through identification of some of the key terms of those documents, such as the type of document, the document identifier, the publisher, the document vintage and the agreement date.
Within Other Agreement
is a set of attributes that defines agreement executed between parties, it consists of the following additional attributes:
Identifier
is a metadata attribute that is used to identify the agreement.
Other Agreement Type
is a metadata attribute that shows the agreement executed between the parties and intended to govern product-specific transactions between those parties.
Unadjusted Date
describes a date field that is subjected to adjustment based on (day
, month
and year
).
The Governing Law
sub-attribute of Contract Detail
represents the law governing the trade and associated contractual product terms.
The Party Contract Details, sub attribute of Contract Details, represents additional contractual information provided by each involved party.
Party Reference
is a set of attributes that describes both the external and global reference that links to this particular data model.
Natural Person Role
is a set of attributes to specify the role(s) that natural person(s) may have in relation to the contract.
Person Reference
is an attribute that references the natural person to whom the role refers to.
Role
is an attribute that specifies a person role that is distinct from the party role.
A set of metadata key that represents, without a qualification, as to whether this party is a legal entity or a natural person.
The Party ID
identifier associated with a party and the scheme standards that is being used (ie 20 digits LEI code).
The person
set of data attributes consists of first name and surname.
Credit Details
is set of data attributes that is associated with the borrower's credit information. It consists of income, employment, and whether the borrower has an existing mortgage which is denoted as as a boolean flag.
A tradable product
represents a financial product that is ready to be traded, ie included in an execution or contract, by associating a specific price and quantity to this product plus an (optional) mechanism for any potential future quantity adjustment.
Counterparty
attributes is an enumerated value (ie Party1 or Party2 ). The Counterparty attribute can then be positioned in the product (eg to specify which counterparty is the payer, receiver etc) with a counterparty type, that is positioned outside of the product definition, and allows the Counterparty attribute to be associated with an actual party reference.
Price Quantity
attribute defines the settlement information as an exchange between two parties of a specified quantity of an asset (the quantity) against a specified quantity of another asset (the price). The settlement can be either cash or physical. In the case of non-cash products, the settlement of the price/quantity would not be specified here and instead would be delegated to the product mechanics as the price/quantity values.
Product attribute defines the underlying product details that is the ready to be traded (ie included in the contract or execution).
Loan Leg
identifies a loan by referencing a product identifier with a set of optional attributes.
Rate Schedule
is a set of attributes defining a schedule of rates or amounts in terms of an initial value and then a series of step date and value pairs.
Credit Agreement Date
specifies the closing date (the date where the agreement has been signed) for the loans in the credit agreement. Funding of the facilities occurs on (or sometimes a little after) the Credit Agreement date. This attribute is used to help identify which of the company's outstanding loans are being referenced by knowing which credit agreement it belongs to.
ISDA Standards Terms Supplement term: Date of Original Credit Agreement.
Trade date
attribute specifies the date which the trade was agreed. The trade date attribute is based on (day
, month
, year
).
Trade Identifier
is a set of data attributes that consist of the 2 sub attributes. It represents identifier(s) that uniquely reference a trade for an identity issuer. A trade can include multiple identifiers (ie a trade that is reported to multiple jurisdictions, and has an associated USI (Unique Swap Identifier) UTI (Unique Trade Identifier).
Assigned Identifier
refers to the issuer and the identifier and its associated version that provides the ability to associate multiple identifiers to one issuer and is consistent with the FpML Party Trade Identifier.
Issuer
is an attribute when specified explicitly alongside the identifier value (instead of being specified by reference to a party).
Collateral
is a set of metadata attributes that defines the obligations of the counterparty that is subjected to credit support requirements.
Within the collateral data type, property information such as the physical address, dwelling and property type would be specified.
Valuation date
defines when payment will occur relative to the valuation date.
Property Valuation
set of attributes specifies final valuation price. This price can be expressed either as an actual amount/currency. The value attribute can reference to another value specified in the swap document.
A demonstration of the modelling and programming of the regulatory reports using the Ellipse mortgage CDM is shown below.
Using the CDM, executable code automatically generated from the model definitions enabled us to simulate the re-creation of the retail mortgage reports for Singapore and the UK referencing the same model.
We took dummy mortgage transactions with the following parameters:
New / first retail mortgage loans
Owner-occupied
One main borrower
A 25-year loan, fixed rate for first 5 years
Reversion to the firm's standard variable mortgage rate after 5 years
Taking these data feeds and generating the functional logic code based on each jurisdictional requirement that referenced the Ellipse mortgage model, we were able to execute the regulatory “reports” that we derived the attributes from, namely PSD001 and MAS 645.
Infrequent backward looking
Different sources of data are not integrated
Granular Data
Common Data Models
Real-Time Information
Integration of Structured & Unstructured Data
Ellipse is led by the BIS Innovation Hub's Singapore Centre. Please contact the team at singapore.centre@bisih.org.
© Bank for International Settlements ("BIS")
Use of this website (TBC) constitutes agreement by users of this website ("Users") with the following terms and conditions.
All copyright and other intellectual property rights in the publications available on this website, including processes, message flows and API specifications contained in the publications ("Ellipse Material") are owned by the BIS. Except as outlined below, all rights are reserved.
Users may use Ellipse Material on the following conditions without obtaining written permission from the BIS (for any other use, BIS permission must be requested by email to singapore.centre@bisih.org)
Subject to clause 2(2) below, Users may use Ellipse Material to develop payments software, products or services. Ellipse Material may not be sold.
Users may use or reproduce a limited extract of Ellipse Material in other publications or products free of charge, provided the BIS is cited as the source and, with respect to translations, a statement is included that the translation is not an official BIS translation. By way of guidance, a "limited extract" means any extract of not more than 400 words of text or two tables or graphs and the underlying data made available by the BIS, and in any case not exceeding 10% of the relevant publication.
Users who maintain an external website may include electronic links to this website (TBC), as long as this:
does not infringe the intellectual property rights of the BIS, in particular with respect to its names, acronyms and logos; and
is not misleading, for instance by implying endorsement by or affiliation with the BIS.
The BIS is an international organisation which fosters cooperation among central banks and other agencies in pursuit of financial and monetary stability. It has no supervisory or regulatory functions or responsibilities. Its banking services are provided exclusively to central banks, monetary authorities and international financial institutions. The BIS does not accept deposits from, or provide banking services or advice to, private individuals or companies. The BIS has set up an Innovation Hub (the “BISIH”) to foster innovation and greater collaboration amongst the central banking community globally, enhance the understanding of financial technology and contribute to the development of innovative solutions to benefit and enhance the financial system.
The Ellipse Material is provided “as is”. The BIS does not warrant or guarantee the accuracy, completeness or fitness for purpose of any information or material on this website. Under no circumstances shall the BIS be liable for any loss, damage, liability or expense suffered in connection with reliance by any person on any such information or material.
Nothing on this website shall be construed as containing any investment recommendation or advice.
Except where expressly stated to the contrary, the views stated in any material on this website are those of the authors thereof and are not necessarily those of the BIS or its member central banks.
The designations used and the presentation of material on this website do not imply the expression of any opinion whatsoever on the part of the BIS concerning the legal status of any country, area or territory or of its authorities, or concerning the delimitation of its frontiers or boundaries.
This website may contain electronic links to other websites. This does not imply any endorsement or responsibility on the part of the BIS with respect to the opinions, ideas, data or products presented on other websites.
Under no circumstances shall the BIS be liable for any loss, damage, liability or expense suffered in connection with the use of this website, including (but not limited to) any fault, error, omission, interruption or delay.
The BIS may at any time without notice:
add to, update or modify material on this website; or
limit access to or discontinue the whole or any part of this website.
Nothing in these terms and conditions shall constitute a waiver of any of the privileges or immunities of the BIS in any jurisdiction.
These terms and conditions are governed by the laws of Switzerland.
In order to pursue its mandate and mission, the BIS processes information about individuals (“Personal Data”). The BIS takes your privacy seriously. This Privacy Notice describes how the BIS collects and processes Personal Data, and how, in doing so, the BIS complies with its Personal Data Protection Policy.
The nature of the Personal Data the BIS collects depends on your relationship with the BIS. Typically, the BIS may process the following Personal Data: contact information (eg name, email, address, postcode, phone number); online information (eg cookies and IP address, if you visit the BIS websites); or contractual information (eg personal details in relation to services provided to the BIS).
The BIS collects and processes personal data only for the legitimate purposes set out herein below and only processes the Personal Data which are relevant to achieve these purposes.
The BIS processes Personal Data in accordance with the following principles:
Lawfulness, Fairness and Transparency: The BIS shall process Personal Data for legitimate purposes, in a fair and transparent manner. Legitimate purposes for the processing of Personal Data are:
Processing is required in order for the BIS to be able to carry out its mandate and mission, purpose and functions;
Processing is necessary in order to protect the vital interests of a natural person;
Processing is necessary for establishing and asserting the status, privileges and immunities of the BIS or its staff members;
Processing is required for the performance of a contract to which the BIS is a party;
Processing is necessary for compliance with the BIS policies procedures and rules;
Processing is required for any other activity of the BIS and the individual has given their express consent for such processing.
Purpose Limitation: Personal Data shall be collected for one or more specified and legitimate purposes, and not further processed in a manner incompatible with those purposes.
Data Minimisation: Processing of Personal Data shall be adequate, relevant and reasonably limited to what is necessary in relation to the legitimate purposes for which Personal Data is processed.
Storage Limitation: The BIS shall retain Personal Data for the duration specified in its applicable retention schedule(s) adopted by the BIS.
Accuracy: Personal Data shall be recorded as accurately as possible and, where necessary, updated to fulfil the legitimate purpose(s) for which it is processed.
Integrity and Confidentiality: Personal Data shall be recorded as accurately as possible and, where necessary, updated to fulfil the legitimate purpose(s) for which it is processed.
Accountability: The BIS has established appropriate accountability and oversight mechanisms.
Your Personal Data will be kept for as long as necessary to fulfil the purposes for which they were collected or to comply with legal or internal policy requirements. The BIS applies criteria to determine the appropriate periods for retaining your Personal Data depending on their purpose and in accordance with the BIS retention policies.
Your Personal Data are protected by appropriate technical and organisational safeguards against unauthorized processing and against accidental loss, destruction, damage, alteration, disclosure, access, or use.
The BIS may share your Personal Data with third parties (eg suppliers or service providers). The BIS will only transfer Personal Data to third parties where they comply with a standard of protection of Personal Data equivalent at least to the level of protection established by the BIS Personal Data Protection Policy.
Right to access Personal Data: You may ask to obtain confirmation by the BIS as to whether or not your Personal Data is being processed, and, where they are processed. Your rights will be subject to the restrictions on the right to access under the BIS Personal Data Protection Policy.
Right to rectification: You may request correction of your Personal Data that you believe is inaccurate or incomplete.
You can exercise your rights to information or rectification by supplying a completed data subject request form in English to the Personal Data Protection Manager at privacy@bis.org or via mail to
Bank for International Settlements c/o Personal Data Protection Manager Centralbahnplatz 2 CH-4002 Basel
Right to lodge a complaint: In the event that you believe that the BIS is not processing your Personal Data in accordance in a manner described in this Privacy Notice, you have the right to lodge a complaint to the BIS’ Personal Data Complaints Panel within 60 calendar days of becoming aware of the BIS failure to process Personal Data in accordance with its Personal Data Protection Policy.
In submitting your complaint, you must provide relevant information, including, but not limited to (i) the reasons why you believe that the BIS has failed to process your personal data in the manner described in this Privacy Notice, (ii) the date on which you were informed or became aware of the BIS failure, and (iii) the remedy being sought.
We ask that you supplement the complaint with (i) a copy of any relevant response to a request for information regarding the processing of your personal data and/or correction provided by the BIS and (ii) all relevant evidence.
You can exercise your right by submitting a data subject complaint by supplying a completed complaint form in English to the BIS Personal Data Complaints Panel at PDCPanel@bis.org or by mail to
Bank for International Settlements c/o Personal Data Complaints Panel Centralbahnplatz 2 CH-4002 Basel
The BIS shall not accept or respond to anonymous complaints.
Failure to submit the complaint in accordance with requirements set out above may result in the complaint being rejected by the Personal Data Complaints Panel.
Ref No | Links |
1. | See for example: |
2. | See for example: |
3. |
This Cookie Notice applies to the BIS website www.bis.org as well as to any related BIS websites or BIS-branded pages on third-party platforms which are operated by or on behalf of the Bank for International Settlements (“BIS Sites”).
Cookies are small text files which are downloaded to the browser directory of your computer or mobile device when you visit a website. They are widely used in order to make websites work, or work more efficiently, as well as to provide information to the owners of the website.
Other tracking technologies, such as web beacons or tags, are used by some content providers in marketing or social media to track and monitor the access of provided content.
There are different types of cookies that can be classified according to their purpose. Also, cookies may be persistent, ie coded with a defined expiry date independent of the duration of the web session, or last only for the session.
The BIS is committed to continuously updating and enhancing its websites. To this end, we use statistical cookies to collect user data in an anonymised and aggregated format to support the optimisation of the provided content and to improve the user experience. Cookies help us to know which pages are the most and least popular and how visitors navigate around our sites. We also use security cookies to support access to BIS websites with restricted features. Cookies may also be placed by third parties on our websites.
Technical cookies, often referred to as strictly necessary cookies, maybe be placed on a website to fulfil its purpose. By definition, without such essential technical functions, the website would not work, or be displayed in a wrong format. BIS websites do not deploy technical processes which would require such strictly necessary technical cookies.
Marketing cookies or beacons, also often referred to as targeting cookies, are used to collect identifiable personal information about visitors of websites. Such cookies identify browsing behaviours, personal interest and product preferences, tracing individual users in support of advertising or marketing campaigns. The BIS does not use or analyse marketing cookies.
The BIS use of cookies is limited to the following types of cookies:
Statistics cookies, also referred to as webmetrics or performance cookies, collect data about how visitors use and navigate websites. These cookies count visits and identify web traffic sources by collecting user data in an anonymised and aggregated format.
The BIS uses the following statistics cookies:
Third-party cookies are set by parties other than the website owner. They enable third-party features or functionality to be provided on or through the website. In cases where visitors of a BIS website follow a link which takes them to a social media homepage, an external application or third-party website, they are leaving the BIS website realm and are subject to the cookie policies of the respective third party. The degree to which third parties are able to place cookies depends on the cookie control preference settings of your browser. The following third-party cookies may be set on a BIS Site:
Third-party cookies related to social media
BIS webpages link to social media websites such as Twitter, LinkedIn, Instagram and or YouTube and may also show embedded social media content. They also link to RSS feeds and BIS videos and podcasts. Social media providers may place cookies, or other tracking technologies, including those set by Google Analytics, or may direct the visitor to websites hosted outside a BIS Site.
Third-party cookies related to service and collaboration partners
The BIS engages service and collaboration partners to facilitate and support BIS processes and services such as recruitment and e-learning, or collaboration services used by the BIS Innovation Hub. Cookies placed by our service and collaboration partners on a BIS Site are limited to support technical functionality, including statistics, preference and security cookies.
Most browsers allow you to manage if and/or how cookies are set and used, and to clear cookies and browser data. Your browser may have settings that let you manage cookies on a site-by-site basis. Please refer to your browser instructions to learn more about your options for managing cookies.
Documentation for the CDM is found at:
Name
Purpose
Expiry
__session
A session cookie that persists for one year
1 year 1 month
__cuid
A visitor cookie that persists for one year in order to track recurring visitors
1 year 1 month
amp_fef1e8
Supports Amplitude product analytics for Gitbook
1 year
Terms
Description
Advanced Analytics
The autonomous or semi-autonomous examination of data or content using sophisticated techniques and tools to discover deeper insights, make predictions, or generate recommendations. Advanced analytic techniques include those such as data/text mining, machine learning, pattern matching, forecasting, visualization, semantic analysis, sentiment analysis, network and cluster analysis, multivariate statistics, graph analysis, simulation, complex event processing, neural networks.
Aggregate Data
Data, typically numerical, that is collected from multiple sources and/or on multiple measures, variables and combined into data summaries, typically for the purposes of public reporting or statistical analysis.
Artificial Intelligence
The theory and development of computer systems able to perform tasks that traditionally have required human intelligence.
Data Attribute
A data attribute is a single field representing a certain feature, characteristic, or dimensions of a data object.
Data Model
Refers to a semantic data model which is a method of organising data that reflects the basic meaning of data items and the relationships among them. This organization makes it easier to develop application programs and to maintain the consistency of data when it is updated.
Data Standards
Data standards are the rules by which data are described and recorded in a consistent way. In order to share, exchange, and understand data, the format and meaning must be standardised.
Exposures
In finance, exposure refers to the amount of money that an investor has invested in a particular asset and also represents the amount of money that the investor could potentially lose on an investment.
Granular Data
The data points and data formats which firms use in their internal books and records for financial and business purposes. Data defined at lowest appropriate level possible for a given data set, for example relating to individual contracts or transactions.
Machine Learning
A method of designing a sequence of actions to solve a problem that optimise automatically through experience and with limited or no human intervention.
Open Source
Open source describes software that comes with permission to use, copy and distribute, either as is or with modifications, and that may be offered either free or with a charge. The source code must be made available.
Predictive Analytics
The use and examination of data to predict patterns of activity. Predictive analytics may involve technologies such as machine learning or visualisation tools and is characterised by techniques such as regression analysis, forecasting, multivariate statistics, pattern matching, predictive modelling, and forecasting.
Proof of Concept
A proof of concept (POC) is a demonstration of a product, service or solution in a sales context. A POC should demonstrate that the product or concept will fulfill customer requirements while also providing a compelling business case for adoption.
Reference implementation
For this POC, we refer to reference implementation as a point of reference rather than being put to directly productive use.
Regulatory reporting
Data received to fulfill mandated functions such as supervisor, regulator, macro prudential authority and Resolution authority.
Reporting requirements
The description of which firms need to provide data, what data they need to provide, how they need to provide it and when they need to provide it. Requirements may include rules, instructions and technical specifications.
Structured Data
Information that has a pre-defined data model or is organised in a predefined manner.
Suptech
Any application of financial technology used by regulatory, supervisory and oversight authorities.
Technology Stack
A list of all the technology services used to build and run one single application.
Unstructured data
Information that either does not have a pre-defined data model or is not organised in a pre-defined manner.
Acronym
Term
AI
Artificial Intelligence
BISIH
Bank for International Settlements Innovation Hub
BoE
Bank of England
CDM
Common Domain Model
FPML
Financial Products Markup Language
ISDA
International Swaps and Derivatives Association
JSON
JavaScript Object Notation
MAS
Monetary Authority of Singapore
ML
Machine Learning
OTC
Over-the-counter
POC
Proof of Concept