Introduction to CRS Client Identification
The Common Reporting Standard (CRS) is an information standard that facilitates the automatic exchange of information developed in the context of the OECD (Organization for Economic Co-operation and Development). Effective since January 01, 2016, it calls on jurisdictions to obtain information from their financial institutions and automatically exchange that information with other jurisdictions on an annual basis. It sets out the financial account information to be exchanged, the financial institutions required to report, the different types of accounts and taxpayers covered, and common due diligence procedures to be followed by the financial institutions.

The following are the main areas of focus under Common Reporting Standard.
CRS can be broken down into the below depicted steps:
Identifying Reporting Financial Institutions
The following diagram enables the user to understand the process flow in identifying a reporting financial institution.
The rules defining Reporting Financial Institutions are built around a four-step test indicated below.
Non-Reporting Financial Institutions are the following:
Reviewing Financial Accounts
Reporting Financial Institutions must review the financial accounts they maintain to identify whether any of them need to be reported to the tax authority.
The specific categories of financial accounts are as follows:
The table below describes who maintains the financial accounts.
Accounts | Financial Institution used to Maintain Them |
---|---|
Depository Accounts | The Financial Institution (FI) obligated to make payments to the account (excluding an agent of an FI). |
Custodial Accounts | The Financial Institution (FI) that holds custody over the assets in the account. |
Equity and debt interest in certain investment entities | The equity or debt interest in an FI is maintained by that FI. |
Cash Value Insurance Contracts | The Financial Institution obligated to make payments related to the contract. |
Annuity Contracts | The Financial Institution obligated to make payments related to the contract. |
Excluded accounts
These accounts are financial accounts considered to be low risk of being used to evade tax and are therefore specifically excluded from being reviewed. These categories are listed in the screenshot below:
Financial Accounts that are Reportable Accounts
Once a Reporting Financial Institution identifies the financial accounts they maintain, they must review those accounts to identify whether any of them are Reportable Accounts as defined in the CRS. If they are found to be Reportable Accounts, information in relation to those accounts must be reported to the tax authority.
A Reportable Account is defined as an account held by one or more Reportable Persons or by a Passive Non-Financial Entity with one or more Controlling Persons that is a Reportable Person.
The diagram below is a reportable account due to the account holder.
The diagram below is a reportable account due to the controlling person.
Due Diligence Procedure
To identify reportable accounts and obtain accurate, required information, financial institutions must follow a common standard with robust due diligence procedures. These procedures distinguish between individual accounts and entity accounts and between pre-existing and new accounts.
One of the key decisions for implementing jurisdictions is the date from which the new account procedures apply. This is the date from which persons that open new accounts must provide additional information for financial institutions to determine where they are tax resident. For accounts opened prior to this date, financial institutions are allowed to rely on the information they hold.

Financial institutions are required to review pre-existing individual accounts without applying of any de minimis threshold, though different procedures apply to higher value accounts and lower value accounts.
- Lower Value Accounts—a country can allow a financial institution to perform an indicia search or to rely on a permanent residence address test. Self-certification (documentary evidence) is needed in case of conflicting indicia. If no such certification can be found, reporting can be carried out to all reportable countries for which indicia is found.
- Higher Value Accounts—enhanced due diligence procedures apply, including a paper record search and a reason to know test for the relationship manager enquiry. The relationship manager of a high value account is the officer or employee of the financial institution, with direct contact and primary responsibility for managing the account.

The CRS contemplates self-certification (and the confirmation of its reasonableness) without de minimis threshold.

Financial institutions determine whether the entity is,
- A reportable person, which is verified based on the information available (AML/KYC procedures), or, through self-certification.
- A passive NFE and must confirm the residency of controlling persons. Where possible, this can be achieved through available information, but requires obtaining a self-certification from an account holder or controlling person of a passive NFE, where applicable.
If the domestic country allows and the individual financial institution elects to apply it, the pre-existing entity accounts below USD 250,000 (or local currency equivalent) are not subject to review until such time as the account exceeds USD 250,000 at the end of the subsequent year.

Financial institutions must follow the same determination similar to pre-existing accounts. However, as it is easier to obtain self-certifications for new accounts as part of account opening process, the USD 250,000 (or local currency equivalent) threshold does not apply.
The residency of controlling persons of passive NFEs must be determined on the basis of self-certifications.
Reportable and Exchangeable Information
Once accounts are determined to be Reportable Accounts, then the Financial Institution must report information in relation to that account to the tax authority. This is the information that a jurisdiction agrees to exchange with its automatic exchange partners as specified in the MCAA, a bilateral CAA or another international basis for the exchange of information, such as the EU DAC2 Directive.
The information is required:
- For the automatic exchange partner jurisdiction to identify the account holder concerned (Identification information).
- To identify the account and the financial institution where the account is held (Account information).
- In relation to the activity taking place in the account and the account balance (Financial information).
CRS Business Workflow
The CRS end to end processing workflow is shown below.
The CRS Solution in Temenos Transact scales through the below processes:
- Balance Aggregation process for the pre-existing and for new accounts.
- Classification of the pre-existing and new accounts into Individuals and Entities.
- Due-Diligence process for the pre-existing and new accounts.
- Process to work out the indicia’s as part of the due-diligence process.
- Recording of the mandatory information for the new accounts.
- Reporting of both pre-existing and new accounts.
Configuring CRS Module Licensing
In Temenos Transact, the CRS functionality is licensed under the following module codes:
- CD module licensing covering Client Identification and Due Diligence
- CE module licensing covering the AEoI Reporting Solution.
The CD module licensing helps banks to identify all reportable customers under the CRS Regulation using the due diligence process.
- The year during which the regulation becomes effective.
- Ability to identify whether the customer having a tax residence in a country under participating jurisdiction and becomes reportable, with a facility for automatic update at regular intervals in case of changes in the jurisdictions.
- Initial Balance Aggregation process for all customers and subsequent aggregations only for CRS customers.
- Classification of customers into individuals & entity segregating balances into high and low values.
- Due Diligence process based on the indicia given by the regulators and capturing of mandatory information for new accounts.
- Holding of clients’ information linked to the codes as prescribed by schema.
The CE module focuses on creation of the XML report in readiness for exchange of information with the Tax authority .
- Reporting is controlled based on high level parameter set up governing CRS Reporting.
- Base file is created to store all the required information for Reporting. Special feature to identify and report Dormant accounts separately
- Provision to amend the base file for corrections, if any
- Generation of XML Report.
Configurations to Support CD Module Features
Following are the configurations to support the features in the CD module:

ST.REGULATORY.PARAMETER
This is a generic transact parameter table to track regulatory specific release or rule book. Using this table, the system performs the required checks before releasing the functionality under an existing Regulations which is licensed by the Temenos client. The ID of this table can be any valid regulation name. Additionally, there are some regulatory specific features which can be controlled using this table.
For CRS, the user is allowed to specify whether update of indicium or automatic creation of Supplementary Info records are allowed during the indicia service.


The following information is captured in this table:
The ID is a valid Regulatory ID. In this context, it is CRS.
Field | Description |
---|---|
GB Desc.1 | Provides the description for the chosen regulation. |
Curr Rule Book | Ranges from 1950–2049, anything before and after the specified year displays an error. |
Prev Rule Book | Displays the previous releases of regulation. Before the value in the Curr Rule Book field is overwritten to reflect the latest release, the system automatically updates the current value before modification to the value in the Prev Rule Book field. |
Auto Create Recs | Provides the bank an option to enable the automatic creation and update of CRS.CUST.SUPP.INFO record for the its customers.
Allowed values are:
|
To view the setup for ST.REGULATORY.PARAMETER
, go to Admin Menu > Compliance and Regulatory Administration > Regulatory Parameter > Regulatory Parameter Setup.

CRS.PARAMETER
This parameter is used for recording the details such as effective date, participating jurisdiction, reporting currency and setting up default conditions required for reporting purposes. The table holds these definitions company wise
Any country included or withdrawn from the regulatory process will lead to the automatic calculation of the Indicia and the reportable jurisdiction based on the option provided here.
The CRS.PARAMETER
table displays the regulatory details at company level. The ID is a valid Company code.
The table below describes some of the key fields in CRS.PARAMETER
.
Field | Description |
---|---|
Partng Juridiction | Lists the participating countries for CRS Regulation. |
Telephone Code | Indicates the telephone code assigned to the value displayed in the Partng Juridiction field. This is an associate field for Partng Juridiction field and displays the telephone code based on the Country. Valid countries are made available in the Temenos Transact COUNTRY table. |
Indicia Calc Rtn | Enables provision to hold the ID to the routine that calculates the Indicia Status. This field is mandatory to calculate the Indicia strength. Clients have the option to use their own routines or use an API supported by Temenos Transact, CRS.GET.INDICIA. |
Close.Rel.Bal.Type | Decides whether the previous day customer balances should be calculated when the CRS Status field is changed to INACTIVE. Allowed Values are: PREVIOUS.MONTH and PREVIOUS.DAY . |
Reporting CCY | Specifies the currency used for Balance Aggregation process. |
Auto Status Update | Displays whether there has been an automatic change in the status. Accepted values are yes and No. If there is a change in Indicia, the system updates the status of this field for CRS Reporting automatically when set as “yes”. |
SC Grace Days | Specifies the maximum number of days for submission of Self-Certification documents by clients.
Also used to calculate the date displayed in the Cut Off Date field in the Req Date field specified in CRS.CUST.SUPP.INFO . |
Account Type | Lists out the different type of accounts for classification of existing accounts. |
Account Sub Type | Specifies further classification of account type to HIGH or LOW based on the balance aggregation. |
Reporting Date | Specifies the reporting date of the account types and it can be set to a current date or a future date. |
Initial Aggr Built | Identifies whether the initial aggregation process for all the existing customers is run. The system updates this field as 'YES', once the initial aggregation is completed. Once this field is set, subsequent aggregation process happens only for CRS reportable customers’, that is, for those customer having a record in CRS.CUST.SUPP.INFO . |
Bal Amt Aggr From | Holds the lower range of the aggregation amount for the corresponding account type for account classification of Pre-Existing accounts. |
Bal Amt Aggr To | Holds the upper range of the aggregation amount for the corresponding account type for account classification. |
Due Diligence Date | Specifies the due diligence dates for Pre-Existing Individual Low, Pre-Existing Individual High and Pre-Existing Entity High accounts. |
Country Rule | Displays whether the country is INDIVIDUAL (one XML file per customer) or BULK (one consolidated XML output). This field is set to BULK in order to trigger the >Merge.Rtn field. |
EB.Transfm.Key | Applies the changes in local XSLT transformation or schema changes. Default EB.TRANSFORM rule applied is 'CRS.REPORT.BASE.XSLT', if this field is left blank.Data in the first multi value position is for XSLT transformation of individual customer specific XMLs. And the second multi-value is used for merged XML output. The below screenshot displays the sample setup for Luxembourg |
Dorm Ident App | Defines the application for identifying dormancy. Allows any Temenos Transact application. |
Dorm Ident Field | Defines the field of the application from where dormancy is identified |
Dorm Ident Operand | Accepts the operands 'EQ' 'NE'. |
Dorm Ident Value | Holds the value of Dorm Ident.Field above. |
EIN | Holds the identification number used by the sending tax administration to identify the Entity Account Holder. |
The following fields help in identifying the Indicia.
Field | Description |
---|---|
Tele Cont Type |
Specifies the contact type for the telephone number to be considered for telephone indicia determination. The system compares this information with the values in Contact Type field in CUSTOMER record during indicia determination. |
Poa Code | Specifies the POA relation to calculate Power of Attorney indicia. To calculate POA at,
|
Incare Of | Specifies the Incare Address Purpose, which is considered for identifying Incare indicia. This information is compared to the values in Address Purpose field in CUSTOMER record during indicia determination. |
Reqd Doc Type |
This multivalued field allows the bank to provide the document type record identifiers as defined by them using the During the document data synchronisation process, the system determines the following:
The system correspondingly updates the CCSI record in line with these changes.
|
The below screenshot displays a sample view of the Regulatory Specific High Level Parameter:
For example:
- The participating jurisdictions are listed out and one of them being set as “DE”.
- The telephone codes correspond to the jurisdiction. For DE the telephone prefix is set as “+49”.
- Reporting currency to be USD
- Auto status update is set as yes
- Close Relationship Balance type to use Previous day.
- For Pre-existing Entity, the sub types are high and low. The Balance amount aggregation up to 249,999 is low and from 250,000 is Account sub type high.
- For Pre-existing Individual, the sub types are high and low. The Balance amount aggregation up to 999,999 is low and from 1,000,000 is Account sub type high.
- For New entity & New individual- by default all accounts are reportable.
- Reporting date and due diligence date are to be fed for all sub types except sub type Entity – Low.
Illustrating Model Parameters
Parameters configured in Model Bank are detailed below:
Illustrating Model Products
Model Products are not applicable for this module.
In this topic