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:

1. The Loan

2. The Borrower

3. 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.

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.

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.

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.

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:

• UK:

• 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”.

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.

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:

1. 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.

2. 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.

3. 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.

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.

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:

1. 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.

2. Engaging with industry on their use of data models and taxonomies for that specific product to explore wider extensibility.

3. Establishing small working-level projects using a narrowly scoped and specific use case and agreeing common data attributes and their definitions “in principle”.

4. Exploring ways in which the requirements for the reporting of those data can be published in programming languages.

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.

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).

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.

The CDM developed by ISDA, is an open-source, standardised, machine-readable and machine-executable blueprint for how financial products are traded and managed across the transaction lifecycle. [3] The product scope of the CDM includes over-the-counter (OTC) derivatives, cash securities, securities financing, and commodities. To ensure re-usability across different markets, the CDM is designed as a composable model whereby financial objects can be constructed bottom-up based on building-block components.

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.

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.

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 [1]. 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 [2]. However, data standardisation more generally remains nascent globally.

Ellipse Terminology and Description

We use the following terms throughout this document.

Acronyms used in this document

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 project is being developed in the following phases.

Ellipse is led by the BIS Innovation Hub's Singapore Centre. Please contact the team at singapore.centre@bisih.org.

A demonstration of the modelling and programming of the regulatory reports using the Ellipse mortgage CDM is shown below.

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.

© Bank for International Settlements ("BIS")

Use of this website (TBC) constitutes agreement by users of this website ("Users") with the following terms and conditions.

Copyright and permissions

1. 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.

2. 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)

   1. Subject to clause 2(2) below, Users may use Ellipse Material to develop payments software, products or services. Ellipse Material may not be sold.

   2. 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.

3. Users who maintain an external website may include electronic links to this website (TBC), as long as this:

   1. does not infringe the intellectual property rights of the BIS, in particular with respect to its names, acronyms and logos; and

   2. is not misleading, for instance by implying endorsement by or affiliation with the BIS.

Disclaimers

1. 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.

2. 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.

3. Nothing on this website shall be construed as containing any investment recommendation or advice.

4. 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.

5. 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.

6. 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.

7. 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.

General

1. The BIS may at any time without notice:

   1. add to, update or modify material on this website; or

   2. limit access to or discontinue the whole or any part of this website.

2. Nothing in these terms and conditions shall constitute a waiver of any of the privileges or immunities of the BIS in any jurisdiction.

3. These terms and conditions are governed by the laws of Switzerland.

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

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.

"documentationIdentification": {
      "otherAgreement": [
           {
              "identifier": "1234XXX23",
              "otherAgrementType": "Retail Mortgage 2016",
              "version": "1.0",
              "unadjustedDate": {
                "day": 6,
                "month": 3,
                "year": 2016
              }
            }
          ]
        }    

• 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.

"governingLaw": "GBEN"

• The Party Contract Details, sub attribute of Contract Details, represents additional contractual information provided by each involved party.

"partyReference": {
    "externalReference": "party1",
    "globalReference": "1ab3e71c"
    },
   "naturalPersonRole": [
       {
           "personReference": {},
           "role": "MainBuyer"
       }
  ]

• 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.

Party

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).

"partyId": [
  { 
  "meta": { "scheme": "http://www.fpml.org/coding-scheme/external/iso17442" }, 
  "value": "ML5798312-1" 
 }

• The person set of data attributes consists of first name and surname.

"person": {
      "value": {
        "firstName": "James",
        "surname": "Smith"
      }
    }

Credit Details

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.

"creditDetails": { 
     "hasAMortgage": "False",
     "employmentStatus": "Employed",
     "income": [
      {
        "incomeAmount": {
                 "value": {
                    "amount": 5000,
                     "unitOfAmount": {
                           "currency": {
                             "value": "GBP"
                             }
                           }
                         }
                       }
                    }

Tradable Product

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.

"tradableProduct": {
      "counterparty": [
        {
          "partyReference": {
            "externalReference": "party1",
            "globalReference": "1ab3e71c"
          },
          "role": "PARTY_1"
        },
        {
          "partyReference": {
            "externalReference": "party2",
            "globalReference": "e6c82f54"
          },
          "role": "PARTY_2"
        }
    

• Counterpartyattributes 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.

  "priceQuantity": [
    {
      "meta": {
        "globalKey": "27a2ef6f"
      },
      "price": [
        {
          "meta": {
            "location": [
              {
                "scope": "DOCUMENT",
                "value": "price-1"
              }
            ]
          },
          "value": {
            "amount": 0.0164,
            "unitOfAmount": {
              "currency": {
                "value": "GPB"
              }
            },
            "perUnitOfAmount": {
              "currency": {
                "value": "GPB"
              }
            },
            "priceType": "INTEREST_RATE"
          }
        }
      ],
      "quantity": [
        {
          "meta": {
            "location": [
              {
                "scope": "DOCUMENT",
                "value": "quantity-1"
              }
            ]
          },
          "value": {
            "amount": 250000,
            "unitOfAmount": {
              "currency": {
                "value": "GBP"
              }
            }
          }
        }
      ]

• 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": {
    "loan": {
      "creditAgreeemtDate": {
        "meta": {
          "globalKey": "3f105d"
        },
        "value": {
          "day": 30,
          "month": 4,
          "year": 2021
        }
      },
      "loanLeg": [
        {
          "rateSpecification": {
            "fixedRate": {
              "meta": {
                "globalKey": "0"
              },
              "rateSchedule": {
                "initialValue": {
                  "address": {
                    "scope": "DOCUMENT",
                    "value": "price-1"
                  }
                }
              }
            }
          }

• 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

Trade date attribute specifies the date which the trade was agreed. The trade date attribute is based on (day, month, year).

"tradeDate": {
  "meta": {
    "globalKey": "3f105d"
  },
  "value": {
    "day": 30,
    "month": 4,
    "year": 2021
  }

Trade Identifier

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).

"assignedIdentifier": [
      {
        "identifier": {
          "meta": {
            "scheme": "http://www.fpml.org/coding-scheme/external/uti"
          },
          "value": "UITD7895394"
        }
      }
    ]

• 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.

  Copy

   "issuer": {      
         "meta": {
         "scheme": "http://www.fpml.org/coding-scheme/external/iso17442"
        },
        "value": "54930084UKLVMY22DS16"
     }

• Issuer is an attribute when specified explicitly alongside the identifier value (instead of being specified by reference to a party).

Collateral

Collateral is a set of metadata attributes that defines the obligations of the counterparty that is subjected to credit support requirements.

"propertyType": "PrivateResidential",
"dwellingType": "ApartmentOrFlat",
"physicalAddress": {
"street": "Sun Street",
"city": "Holbrokk",
"country": {
     "meta": {
          "scheme": "http://www.fpml.org/coding-scheme/external/iso3166"
          },
     "value": "GBR"    

• Within the collateral data type, property information such as the physical address, dwelling and property type would be specified.

    "ValuationDate": {
      "meta": {
        "globalKey": "3f105d"
      },
      "value": {
        "day": 15,
        "month": 4,
        "year": 2021
      }

• Valuation date defines when payment will occur relative to the valuation date.

"PropertyValuation":
  {
  "address":
   { 
   "scope": "DOCUMENT", 
    "value": "price-2"
   } 
  },
  "PurchasePrice": {
    "address": { "scope": "DOCUMENT", 
    "value": "price-3" 
    }
  }

• 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.

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.

What kind of personal data does the BIS collect and for which purpose?

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.

What are the principles of the BIS Personal Data Protection Policy and the legitimate purposes for which the BIS processes personal data?

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.

How long does the BIS keep your Personal Data?

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.

How does the BIS protect your Personal Data?

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.

With whom and how does the BIS share your Personal Data?

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.

What are your rights and how can you exercise them?

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.

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.

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.

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”).

What are cookies?

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.

Why do we use cookies?

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.

Which cookies do we use?

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.

How do you manage 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.

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.

Links to the technical documentation associated with the CDM can be found in the Annex under References [3].