Reporting Format Guide Version 2.0
Reporting Format Guide Version 2.0
Version 2.1
Remarks Fixed width multiple data files reporting format (Refer section 1.2 for details) XML reporting format prepared under Project FINnet Changes in following sections due to implementation of digital signature in the Report Validation Utility. Report Validation Utility (section 5.2) FINnet Gateway Portal (section 6.1) Submission of Reports (section 6.2) FAQs (section 6.5) element Batch/Report/Transaction (section 12.1.8)
Version 2.1
Contents 1 1.1 1.2 1.3 1.4 2 2.1 Background .......................................................................................................................1 About FIU-IND .................................................................................................................1 Earlier reporting formats ..................................................................................................1 Project FINnet ..................................................................................................................1 Need for modifications in reporting format .......................................................................1 About this Document........................................................................................................2 Version Information .........................................................................................................2
Changes in this version ................................................................................................... 2 Document version naming convention ............................................................................. 2
2.1.1 2.1.2
Reporting formats .............................................................................................................3 Reports prescribed under PMLA .....................................................................................3 Types of reporting formats ...............................................................................................3 Mapping of report type to reporting format ......................................................................3 Frequently Asked Questions (FAQs) ...............................................................................3
What was the need to modify reporting format? .............................................................. 3 What are the reports prescribed under PMLA?................................................................ 4 What are the types of reporting formats?......................................................................... 4 What are the changes in reporting formats from version 1.0 to 2.0? ................................ 4 Which reporting format should be used for submitting CTR, STR and NTR? ................... 4 Which reporting format should be used for submitting CCR? .......................................... 4 Whether both CTR and STR have a common format? .................................................... 4 Whether CTR and STR can be submitted in the same batch?......................................... 4
4 4.1
4.2
4.2.1 4.2.2
Version 2.1
4.2.3
4.3 4.4
5 5.1
Report Validation Utility .................................................................................................16 Editable pdf based Utility ...............................................................................................16 Frequently Asked Questions (FAQs) .............................................................................17
What is Report Generation Utility? ................................................................................ 17 What is Report Validation Utility? .................................................................................. 17 What are the rules for generation of XML reports from variants of text files (v 1.0)? ...... 17 What are the prerequisites for generation of XML from text files?.................................. 17 What are the key validation rules for text files?.............................................................. 17 What are the XML generation rules for text files? .......................................................... 17 What codes can be used in element BranchRefNum to identify branches? ................... 17
Submission of Reports to FIU-IND ................................................................................18 FINnet Gateway Portal ..................................................................................................18 Submission of reports over the FINnet Gateway ...........................................................18 Submission of reports on CDs .......................................................................................19 Submission of reports by other means ..........................................................................19
Version 2.1
6.5
6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 6.5.6 6.5.7 6.5.8 6.5.9 6.5.10
Data Quality Validation ...................................................................................................22 Types of validation .........................................................................................................22 Types of Errors ..............................................................................................................22 Validation Error Matrix ...................................................................................................22 XML Schema Validation (XSV) ......................................................................................23 Preliminary Rule Validation (PRV) .................................................................................23 Advanced Rule Validation (ARV) ...................................................................................24 Data Quality Rating .......................................................................................................25 Data Quality Report .......................................................................................................25 Resolution of errors .......................................................................................................25 Frequently Asked Questions (FAQs) ..........................................................................25
What are the types of data quality validation? ............................................................... 25 What are the types of errors checked during data quality validation? ............................ 26 What is XML Schema Validation (XSV)? ....................................................................... 26 What is Preliminary Rule Validation (PRV)? .................................................................. 26 What is Advanced Rule Validation (ARV)? .................................................................... 26 What is Data Quality Rating? ........................................................................................ 26 What is Data Quality Report? ........................................................................................ 26 How should Reporting Entities resolve errors? .............................................................. 26
7.10
7.10.1 7.10.2 7.10.3 7.10.4 7.10.5 7.10.6 7.10.7 7.10.8
Version 2.1
Modification of earlier submitted report .......................................................................27 Rejection of reports .......................................................................................................27 Resubmission of rejected report ....................................................................................27 Submission of additional information .............................................................................28 Modification of an incorrect report .................................................................................28 Deletion of an incorrect report .......................................................................................28 Relevant Reporting Format Specifications ....................................................................28
Batch Details ................................................................................................................. 28 Report details ................................................................................................................ 30
8.6.1 8.6.2
8.7
Submission of additional information related to submitted report ............................31 Request based submission of additional information.....................................................31 Request based submission of additional documents .....................................................31 Suo moto submission of additional documents..............................................................31 Frequently Asked Questions (FAQs) .............................................................................31
When should additional information related to previous report be submitted? ............... 31 What is request based submission of additional information?........................................ 31 What is request based submission of additional documents? ........................................ 32 What is suo moto submission of additional documents?................................................ 32
10 11
List of additional documents and files..........................................................................33 Annexure A - Account based Reporting format (ARF) ................................................34 Annexure A.1 Schema Documentation for AccountBasedReport.xsd .....................34
element Batch ............................................................................................................... 34 element Batch/BatchHeader.......................................................................................... 36 element Batch/ReportingEntity ...................................................................................... 38
11.1
11.1.1 11.1.2 11.1.3
Version 2.1
11.1.4 11.1.5 11.1.6 11.1.7 11.1.8 11.1.9 11.1.10 11.1.11 11.1.12 11.1.13 11.1.14 11.1.15 11.1.16 11.1.17 11.1.18 11.1.19 11.1.20
element Batch/PrincipalOfficer ...................................................................................... 41 element Batch/BatchDetails .......................................................................................... 43 element Batch/Report.................................................................................................... 47 element Batch/Report/SuspicionDetails......................................................................... 48 element Batch/Report/Account ...................................................................................... 54 element Batch/Report/Account/AccountDetails ............................................................. 56 element Batch/Report/Account/Branch .......................................................................... 61 element Batch/Report/Account/Branch/BranchDetails ................................................... 63 element Batch/Report/Account/Branch/BranchDetails/BranchAddress .......................... 64 element Batch/Report/Account/Branch/BranchDetails/BranchPhone ............................ 64 element Batch/Report/Account/PersonDetails ............................................................... 64 element Batch/Report/Account/PersonDetails/CommunicationAddress......................... 67 element Batch/Report/Account/PersonDetails/Phone .................................................... 67 element Batch/Report/Account/PersonDetails/Individual ............................................... 68 element Batch/Report/Account/PersonDetails/LegalPerson .......................................... 70 element Batch/Report/Account/Transaction .................................................................. 72 element Batch/Report/Account/Transaction/ProductTransaction ................................... 75
11.2
11.2.1 11.2.2 11.2.3 11.2.4 11.2.5 11.2.6 11.2.7
11.3
11.3.1 11.3.2 11.3.3 11.3.4
Version 2.1
12
Annexure B Transaction based Reporting format (TRF) ..........................................94 Annexure B.1 - Schema Documentation for TransactionBasedReport.xsd ................94
element Batch ............................................................................................................... 94 element Batch/BatchHeader.......................................................................................... 94 element Batch/ReportingEntity ...................................................................................... 94 element Batch/PrincipalOfficer ...................................................................................... 94 element Batch/BatchDetails .......................................................................................... 94 element Batch/Report.................................................................................................... 95 element Batch/Report/SuspicionDetails......................................................................... 96 element Batch/Report/Transaction .............................................................................. 102 element Batch/Report/Transaction/CustomerDetails ................................................... 108 element Batch/Report/Transaction/CustomerDetails/CustomerAddress ...................... 110 element Batch/Report/Transaction/CustomerDetails/Phone ........................................ 111 element Batch/Report/Branch ..................................................................................... 111 element Batch/Report/Branch/Address ....................................................................... 113 element Batch/Report/Branch/Phone .......................................................................... 113 element Batch/Report/PaymentInstrument .................................................................. 114 element Batch/Report/RelatedPersons........................................................................ 116 element Batch/Report/RelatedPersons/CommunicationAddress ................................. 118 element Batch/Report/RelatedPersons/Phone ............................................................ 118 element Batch/Report/RelatedPersons/Individual........................................................ 119 element Batch/Report/RelatedPersons/LegalPerson ................................................... 122
12.1
12.1.1 12.1.2 12.1.3 12.1.4 12.1.5 12.1.6 12.1.7 12.1.8 12.1.9
12.1.10 12.1.11 12.1.12 12.1.13 12.1.14 12.1.15 12.1.16 12.1.17 12.1.18 12.1.19 12.1.20
12.2
12.2.1 12.2.2 12.2.3 12.2.4 12.2.5 12.2.6 12.2.7
12.3
12.3.1
Version 2.1
Mandatory Validation Rule Matrix ................................................................................ 136 Other rules for Preliminary Rule Validation (PRV) ....................................................... 138 Sample Rules for Advanced Rule Validation (ARV) ..................................................... 139
13
Annexure C - Counterfeit Currency Reporting format (CRF) ....................................140 Annexure C.1 - Schema Documentation for CCRBasedReport.xsd .........................140
element Batch ............................................................................................................. 140 element Batch/BatchHeader........................................................................................ 140 element Batch/ReportingEntity .................................................................................... 140 element Batch/PrincipalOfficer .................................................................................... 140 element Batch/BatchDetails ........................................................................................ 140 element Batch/Report.................................................................................................. 140 element Batch/Report/Branch ..................................................................................... 142 element Batch/Report/Branch/BranchDetails .............................................................. 142 element Batch/Report/Branch/BranchDetails/BranchAddress ..................................... 142 element Batch/Report/Branch/BranchDetails/BranchPhone ........................................ 142 element Batch/Report/ReportSummary ....................................................................... 143 element Batch/Report/TransactionDetails ................................................................... 146
13.1
13.1.1 13.1.2 13.1.3 13.1.4 13.1.5 13.1.6 13.1.7 13.1.8 13.1.9
13.2
13.2.1 13.2.2 13.2.3 13.2.4
13.3
13.3.1 13.3.2 13.3.3 13.3.4
14
Annexure D Data Quality Report (DQR) ...................................................................155 Annexure D.1 - Schema Documentation for DataQualityReport.xsd ........................155
element DataQualityReport ......................................................................................... 155 element DataQualityReport/BatchHeader.................................................................... 156 element DataQualityReport/ReportingEntity ................................................................ 156
14.1
14.1.1 14.1.2 14.1.3
Version 2.1
14.1.4 14.1.5 14.1.6 14.1.7 14.1.8 14.1.9 14.1.10 14.1.11 14.1.12 14.1.13 14.1.14 14.1.15 14.1.16 14.1.17 14.1.18 14.1.19
element DataQualityReport/PrincipalOfficer ................................................................ 156 element DataQualityReport/BatchDetails .................................................................... 156 element DataQualityReport/AckSummary ................................................................... 157 element DataQualityReport/AckSummary/FatalErrorCount ......................................... 159 element DataQualityReport/AckSummary/NonFatalErrorCount................................... 160 element DataQualityReport/AckSummary/FatalPreliminaryCount ............................... 161 element DataQualityReport/AckSummary/NonFatalPreliminaryCount ......................... 162 element DataQualityReport/AckSummary/FatalAdvancedCount ................................. 163 element DataQualityReport/AckSummary/NonFatalAdvancedCount ........................... 164 element DataQualityReport/PreliminaryValidation ....................................................... 165 element DataQualityReport/PreliminaryValidation/BatchLevelErrors ........................... 166 element DataQualityReport/PreliminaryValidation/ReportLevelErrors ......................... 167 element DataQualityReport/PreliminaryValidation/ReportLevelErrors/ReportError ...... 168 element DataQualityReport/AdvancedValidation ......................................................... 168 element DataQualityReport/AdvancedValidation/BatchLevelErrors ............................. 169 element DataQualityReport/AdvancedValidation/ReportLevelErrors ........................... 169
15 16 17
Annexure E - State Codes ............................................................................................170 Annexure F - Country Codes (ISO 3166) .....................................................................171 Annexure G - Currency Codes (ISO 4127) ..................................................................178
Version 2.1
Background
The Prevention of Money laundering Act, 2002 (PMLA) and the Rules there under requires every reporting entity (banking company, financial institution and intermediaries) to furnish prescribed reports to FIU-IND.
1.1
About FIU-IND
The Government of India has set up Financial Intelligence Unit India (hereinafter called FIU-IND) to coordinate and strengthen collection and sharing of financial intelligence through an effective national, regional and global network to combat money laundering and related crimes. FIU-IND is the national agency responsible for receiving, processing, analyzing financial transactions and disseminating information related to suspect transactions to various national intelligence/enforcement agencies.
1.2
Since 2006, the regulators and FIU-IND had worked together to prescribe electronic reporting formats for various sectors as under: Document CTR, STR formats for Banking Companies CTR, STR formats for Intermediaries CTR, STR formats for Insurance companies CTR, STR formats for Casinos CCR format CTR, STR formats for Authorised Persons CTR, STR formats for Payment System Operators Version 1.0 1.0 1.0 1.0 1.0 1.0 1.0 Prescribed by RBI on 15.02.2006 SEBI on 20.03.2006 IRDA on 31.03.2006 Goa Government on 24.12.2009 RBI on 22.05.2008 RBI on 27.11.2009 RBI on 22.12.2009
1.3
Project FINnet
Financial Intelligence Unit India (FIU-IND) initiated project FINnet (Financial Intelligence Network) in 2007 with the objective to Adopt industry best practices and appropriate technology to collect, analyze and disseminate valuable financial information for combating money laundering and related crimes. Key objectives of Project FINnet are to build efficient system for collection of data; reduce the lead time in processing the data; build capacity to effectively analyze large number of reports and produce quality intelligence.
1.4
With the implementation of Project FINnet (Financial Intelligence Network) by FIU-IND in 2010, the earlier fixed width multiple data files reporting format is replaced by a new single XML file format. The earlier specified reporting formats are being modified to: Move to XML based format which has become the default for most reporting systems Consolidate reporting formats to reduce number of formats Support effective report management Support effective data quality validation and feedback Resolve reporting format related issues raised by various reporting entities
Version 2.1
The reporting format guide provides reporting entities with the specifications of prescribed reports required to be submitted to the Financial Intelligence Unit India (FIU-IND). This document presents details of the XML schema and provides implementation guidance to the reporting entities in preparation and submission of reports. Section 3 provides an overview of the reports prescribed under PMLA and reporting formats to be used by the reporting entities for submission of reports to FIU-IND. Section 4 gives an overview of XML format and fixed width text file format specifications. The detailed reporting format specifications are given in the Annexure. Section 5 contains information related to preparation of prescribed reports by the reporting entities and the Report Generation Utility, Report Validation Utility and Editable pdf based Utility developed by FIU-IND. Section 6 provides information related to submission of reports to FIU-IND and gives an overview of the FINnet Gateway Portal which has been developed as a comprehensive interface for the reporting entities. Section 7 explains the data quality validation approach adopted by FIU-IND covering the XML Schema validation, rule based validation, types of errors and Data Quality Report. Section 8 contains information about modification of earlier submitted report. Issues related to submission of additional information or documents related to a previously submitted report are covered in section 9. Section 10 lists out other document and files containing additional information related to submission of report. Annexure to this guide contain detailed reporting format specifications.
2.1
Version Information
The current version of Reporting Format Guide is 2.1 2.1.1 Changes in this version
In this version, the changes with respect to process of securing XML file using digital signature and submission of reports through FINnet Gateway portal are incorporated. In version 2.0, the reporting formats were changed from the fixed width multiple data file format to a new single XML file format. XML is versatile and has a powerful syntax to represent data in a sufficiently neutral way for all applications to handle. A few data elements were added, along with marginal modifications to the existing data elements from the existing reporting format version 1.0. 2.1.2 Document version naming convention
The version of the document is specified as X.Y and version changes are defined as under: Version Element X Y Change denoted Change in reporting format Change in instructions for filling the report Remarks The reporting format version 2.0 indicates that the reporting format has changed from the earlier version 1.0 The changes in instructions in how to fill the report are communicated in version 2.1 and so on
Version 2.1
Reporting formats
This section describes the types of reports under PMLA and provides an overview of reporting formats to be used by the reporting entities for submission of reports to FIU-IND.
3.1
The Prevention of Money laundering Act, 2002 and the Rules there under requires every reporting entity (banking company, financial institution and intermediaries) to furnish the following reports: Cash Transaction reports (CTRs) Suspicious Transaction Reports (STRs) Counterfeit Currency Reports (CCRs) Non Profit Organisation Transaction reports (NTRs)
3.2
These reporting formats will replace all the earlier prescribed reporting formats.
3.3
The applicable reporting format will depend on the type of transactions that are being reported. The mapping of prescribed reports to the reporting formats is as under: Report Type Cash transaction Report (CTR) Suspicious transaction Report (STR) Non Profit Organisation Transaction Report (NTR) Counterfeit Currency Report (CCR) Applicable Reporting Format Account based reporting format (ARF) for Account based transactions Transaction based reporting format (TRF) for other Transactions (Transactions without account based relationship with the customer. E.g. money transfer service, money exchange ) CCR reporting format (CRF)
3.4
3.4.1
With the implementation of Project FINnet (Financial Intelligence Network) by FIU-IND in 2010, the earlier fixed width multiple data files reporting format is replaced by a new single XML file format. The earlier specified reporting formats are being modified to: Move to XML based format which has become the default for most reporting systems Consolidate reporting formats to reduce number of formats Support effective report management
Version 2.1
3.4.2
Support effective data quality validation and feedback Resolve reporting format related issues raised by various reporting entities What are the reports prescribed under PMLA?
The Prevention of Money laundering Act, 2002 and the Rules there under requires every reporting entity (banking company, financial institution and intermediaries) to furnish the following reports: 3.4.3 Cash Transaction reports (CTRs) Suspicious Transaction Reports (STRs) Counterfeit Currency Reports (CCRs) Non Profit Organisation Transaction reports (NTRs) What are the types of reporting formats?
The reporting formats specified in the reporting format guide are: 3.4.4 Account based reporting format (ARF) for reporting of account based CTRs, STRs and NTRs Transactions based reporting format (TRF) for reporting of transaction based CTRs, STRs and NTRs CCR reporting format (CRF) for reporting of counterfeit currency reports (CCRs) What are the changes in reporting formats from version 1.0 to 2.0?
In this version, the reporting formats have changed from the fixed width multiple data file format to a new single XML file format. XML is versatile and has a powerful syntax to represent data in a sufficiently neutral way for all applications to handle. A few data elements have been added, along with marginal modifications to the existing data elements from the existing reporting format version 1.0. 3.4.5 Which reporting format should be used for submitting CTR, STR and NTR?
If the reporting entity has account-based relationship, they should use account based reporting format (ARF) for submitting CTR, STR and NTR. Transaction based reporting format (TRF) can be used for transactions without account based relationship with the customer. E.g. money transfer service, money exchange. 3.4.6 Which reporting format should be used for submitting CCR?
Counterfeit currency reporting format (CRF) should be used for submitting CCR. 3.4.7 Whether both CTR and STR have a common format?
Yes. CTR and STR have a common format and certain elements related to suspicion are not required to be reported in CTR. Refer section 4.3 of Reporting Format Guide for details. 3.4.8 Whether CTR and STR can be submitted in the same batch?
No. One batch can contain only one prescribed type of report.
Version 2.1
This section and the annexure describe the detailed format specifications of the prescribed reports required to be submitted to FIU-IND. The reporting format specifications are prescribed as XML format specifications and manual reporting formats. In addition, fixed width text file format specifications specified earlier are also revised as version 2.0 to assist reporting entities in migration to the XML format specifications.
4.1
The XML format specifications are the prescribed specifications to be used by the reporting entities for submission of reports to FIU-IND. The XML schema is published as a separate file with .XSD extension. The details of XML format specification is given in Annexure to this document. The base version of the XML format specifications is 2.0 to ensure consistency with fixed width text file format specifications. FIU-IND has developed a Report Generation Utility which can be used by reporting entities to generate XML report files from captured data or text files. 4.1.1 Overview of XML
XML stands for eXtensible Markup Language. XML is designed to transport and store data. Important features about XML are: 4.1.2 XML documents must contain a root element. The root element is "the parent" of all other elements. The elements in an XML document form a document tree. The tree starts at the root and branches to the lowest level of the tree. Elements are used to classify data in an XML document so that the data becomes "self-explanatory". Opening and closing tags represent the start and end of an element. The element in XML can be simple or complex. A complex element is an XML element that contains other elements and/or attributes). An XML Schema describes the structure of an XML document. The XML Schema language is referred to as XML Schema Definition (XSD). XML with correct syntax is "Well Formed" XML. XML validated against an XML Schema is "Valid" XML. Overview of XML Schema Definition Files
The XML format specifications are specified in XML Schema Definition (XSD) files and explained in Annexure as under: S. No. 1 2 3 Reporting Format Account based reporting format Transaction based reporting format CCR based reporting format Name of XSD file AccountBasedReport.xsd TransactionBasedReport.xsd CCRBasedReport.xsd Annexure Annexure A.1 Annexure B.1 Annexure C.1
In addition to the above XSD files, the common elements have been consolidated in FIU-INDSchemaLibrary.xsd.
Version 2.1
The XML Schema Definition (XSD) files define the structure of XML file containing data of a batch of reports. Each batch contains reports of the same type. All the reporting formats (i.e. Account based reporting format, Transaction based reporting format and Counterfeit Currency based reporting format) have similar structure consisting of batch level and report level information. Figure: Overview of a Batch of Reports
4.1.3
Schema Documentation Image Description Mandatory single element Optional single element Multiple single element Mandatory complex element (i.e. at least one child element) Optional complex element
Sequence compositor (defines the order in which child elements occur) Choice compositor
4.2
The fixed width text file format specifications represent the required intermediate data set to generate XML reports. The existing fixed width text file format specification (version 1.0) has been upgraded to version 2.0 to ensure compatibility with the XML format specifications. The reporting entities are required to submit reports to FIU-IND
Version 2.1
which is compliant with the XML format specifications and the fixed width text file format specifications have been described to assist the extraction of data from the information system of reporting entities before preparation of XML reports. Reporting entities are encouraged to shift to the fixed width data structure version 2.0 before generating XML reports at their end. Reporting entities which have necessary technical capabilities may like to shift to generation of XML reports directly. The fixed width text file format specifications are given in following Annexure S. No. 1 2 3 Type of text files Account based text files Transaction based text files Counterfeit currency based text files Annexure Annexure A.2 Annexure B.2 Annexure C.2
All data files should comply with following requirements: i) ii) iii) All Data Files should be generated in ASCII Format with ".txt" as filename extension. All CHAR fields must be left justified. If CHAR field has no data or less data with respect to defined length, then the entire field (in case of no data) or the remaining field (in case of less data) has to be filled with right justified blank characters (Spaces). All NUM fields must be right justified. If NUM field has no data or less data with respect to defined length, then the entire field (in case of no data) or the remaining field (in case of less data) has to be filled with left justified zeroes. If DATE field has no data then the entire field has to be filled with blank characters (Spaces). Fields with an asterisk (*) have to be compulsorily filled up. For fields that do not have an asterisk (*), reasonable efforts have to be made to get the information. Enter NA to indicate that the field is not applicable. Do not substitute any other abbreviations or special characters (e.g., x, - or *). ARF (Account based) text files
4.2.1
The version 2.0 of the data structure comprises of the following seven data files: S. No. 1 2 3 4 5 6 7 Filename ARFBAT.txt ARFRPT.txt ARFBRC.txt ARFACC.txt ARFTRN.txt ARFINP.txt ARFLPE.txt Description Batch File Report File Branch File Account File Transaction File Individual Person File Legal Person/Entity File
The description of the data files is given in Annexure A.2. 4.2.1.1 Steps in preparation of ARF (account based) text files The steps in preparation of data files are:
Version 2.1
v)
The records containing details of suspicious transactions to be reported are extracted in Transaction Data File (ARFTRN.txt). The records containing details of accounts with the suspicious transactions are extracted in Accounts Data File (ARFACC.txt). If the account is for Individuals, the records containing details of Individuals who are account holders are extracted in Individual Data File (ARFINP.txt). The Relation Flag should be set to A. If the account is for a Legal Person/Entity, the records containing details of Legal Persons/Entities who are account holders are extracted in Legal Persons/Entities Data File (ARFLPE.txt). The Relation Flag should be set to A. Similarly for other Individuals/Legal entities related to the account in different capacities, the records containing the details are appended to Individual data file (ARFINP.txt) or Legal persons/Entities data file (ARFLPE.txt) as the case may be. The relation flag may be set as per section 11.1.14.1. The records containing details of branches which have reported suspicious transactions are extracted in Branch Data File (ARFBRC.txt). The grounds of suspicion and report level details are entered in Report file. (ARFRPT.txt) TRF (transaction based) text files
The version 2.0 of the data structure comprises of the following seven data files: S. No. 1 2 3 4 5 6 7 Filename TRFBAT.txt TRFRPT.txt TRFBRC.txt TRFTRN.txt TRFPIN.txt TRFINP.txt TRFLPE.txt Description Batch File Report File Branch File Transaction File Payment Instrument File Individual Person File Legal Person/Entity File
The description of the data files is given in Annexure B.2. 4.2.2.1 Steps in preparation of TRF (transaction based) text files The steps in preparation of data files are: i) The records containing details of suspicious/cash transactions have to be extracted in Transaction Data File (TRFTRN.txt). If one or more related individuals/entities have undertaken multiple transactions, all such transactions should be included in one STR. The records containing details of branches/locations related to the transactions have to be extracted in Branch Data File (TRFBRC.txt). The relation flag has to be set accordingly. If multiple branches/locations are related to the suspicious transactions, details of such all such branches/locations should be included in the STR. If other Institutions are related to the transactions (Payment Instrument Institution, Account Institution and Related Institution) and their information is available with the reporting entity, their details have to be extracted in Branch Data File (TRFBRC.txt). The relation flag has to be set accordingly. If details of payment instrument(s)/card(s) related to the transactions are available, their details have to be extracted in Payment Instrument File (TRFPIN.txt).
ii)
iii)
iv)
Version 2.1
v)
vi)
vii)
viii) 4.2.3
If details of individual(s) related to the transactions are available, the records containing details of individuals have to be extracted in Individual Data File (TRFINP.txt). The relation flag has to be set accordingly If details of Legal Person/Entity(s) related to the transactions are available, the records containing details of Legal Person/Entity have to be extracted in Legal Person/Entity Data File (TRFLPE.txt). The relation flag has to be set accordingly. If the details of Legal Person/Entity have been extracted to Legal Person/Entity File (TRFLPE.txt), the records containing details of Authorised Signatories or Directors/Partner/Members etc. of Legal Persons/Entities may be appended to Individual Data File (TRFINP.txt). The grounds of suspicion and report level details have to be captured in the Report file (TRFRPT.txt). CRF (counterfeit currency based) text files
The version 2.0 of the data structure comprises of the following four data files: S. No. 1 2 3 4 Filename CRFBAT.txt CRFRPT.txt CRFBRC.txt CRFTRN.txt Description Batch File Report File Branch File Transaction File
The description of the data files is given in Annexure C.2. 4.2.3.1 Steps in preparation of CRF (counterfeit currency based) text files The steps in preparation of data files are: i) The details of counterfeit currency should be captured in the Report File (CRFRPT.txt). ii) The details of branches should be captured in the Branch File (CRFBRC.txt). iii) The Batch level details and summary should be captured in the Batch file. (CRFBAT.txt) iv) The serial numbers of the counterfeit currency may be captured in the Transaction File (CRFTRN.txt)
4.3
Manual Reporting Formats have been specified as editable PDF forms which can be used by reporting entities to print the report and submit as a paper based report. The Editable pdf form based utility enables users to enter or import data, validate for errors and generate XML reports for submission through the secure FINnet Gateway Portal. Alternately, Reporting Entities can print the report in OCR compatible format and post the paper based report to FIU-IND. The reporting entity must submit all reports to FIU-IND in XML format specifications if it has the technical capability to do so. The data of submitted reports can be saved in the editable PDF document. The various types of manual reporting formats are i) ii) iii) iv) v) Cash Transaction Report (Account Based) Cash Transaction Report (Transaction Based) Suspicious Transaction Report (Account Based) Suspicious Transaction Report (Transaction Based) Counterfeit Currency Report
The format for Cash Transaction Report can be used for preparing NPO transaction report.
Version 2.1
4.4
4.4.1
XML stands for eXtensible Markup Language. XML is designed to transport and store data. Important features of XML are given in section 4.1. 4.4.2 What is XSD?
The XML Schema Definition (XSD) files define the structure of XML file containing data of a batch of reports. Each batch contains reports of the same type. All the reporting formats (i.e. Account based reporting format, Transaction based reporting format and Counterfeit Currency based reporting format) have similar structure consisting of batch level and report level information. 4.4.3 What is fixed width text files version 2.0?
The fixed width text file format specifications represent the required intermediate data set to generate XML reports. The reporting entities are required to submit reports to FIU-IND which is compliant with the XML format specifications. The fixed width text file format specifications have been described to assist the extraction of data from the information system of reporting entities before preparation of XML reports. The existing fixed width text file format specification (version 1.0) has been upgraded to version 2.0 to ensure compatibility with the XML format specifications. Reporting entities are encouraged to shift to the fixed width data structure version 2.0 before generating XML reports at their end. Reporting entities which have necessary technical capabilities may like to shift to generation of XML reports directly. 4.4.4 What are the common requirements of fixed width text files version 2.0?
All data files should comply with certain requirements to ensure that the reports can be processed without data errors. Refer section 4.2 of Reporting Format Guide for details. 4.4.5 How many data files are required in ARF (Account based) text files?
The version 2.0 of the data structure comprises of seven data files. Refer section 4.2.1 of Reporting Format Guide for details. 4.4.6 How many data files are required in TRF (Transaction based) text files?
The version 2.0 of the data structure comprises of seven data files. Refer section 4.2.2 of Reporting Format Guide for details. 4.4.7 How many data files are required in CRF (counterfeit currency based) text files?
The version 2.0 of the data structure comprises of four data files. Refer section 4.2.3 of Reporting Format Guide for details. 4.4.8 What are the steps in preparation of text files?
Refer section 4.2.1, 4.2.2 and 4.2.3 of Reporting Format Guide for ARF, TRF and CRF respectively.
10
Version 2.1
Preparation of reports
This section contains information related to preparation of prescribed reports by the reporting entities. This section also gives an overview of the Report Generation Utility, Report Validation Utility and Editable pdf based Utility developed by FIU-IND to assist reporting entities in the preparation of the prescribed reports. The reporting entities are required to submit reports to FIU-IND which is compliant with the XML format specifications. Reporting entities which have necessary technical capabilities may generate XML reports directly from their systems. The reporting format guide also specifies text file format specifications to assist in the extraction of data from the information system of reporting entities before preparation of XML reports. Reporting entities are encouraged to shift to the fixed width data structure version 2.0 before generating XML reports at their end. FIUIND has developed a Report Generation Utility to assist the reporting entities in generation of XML reports.
5.1
The Report Generation Utility enables user to generate XML report from various data sources. The broad features of the Report Generation Utility are: Capture data in XML tree structure and Grid structure (version 2.0) Import data from previously saved XML file or Grid data Perform key and structural validations before generation of XML Generate XML report from loaded data or direct conversion of fixed width text files (version 1.0 and 2.0) Configure the settings and preferences of the utility
The user guide for RGU provides detailed documentation on using the utility. The Report Generation Utility performs key and structural validation checks on the data files before generation of XML files. The validation checks performed on the version 1.0 data files is given in respective reporting formats and section 5.1.4. The prerequisite rules for generation of XML reports from the respective version 2.0 text files are given in following sections. 5.1.1 Generation of XML reports from ARF (account based) text files (v 2.0)
The rules for checking the data files and the conversion rules for generation of XML reports are given in following sections. 5.1.1.1 Prerequisites for generation of XML from ARF text files The rules for checking ARF (account based) data files (version 2.0) are: i) ii) iii) iv) There should be seven data files with appropriate naming convention. The data files should be as per specified data structure and business rules. None of the mandatory fields should be left blank. All dates should be entered in YYYY-MM-DD format.
5.1.1.2 Key validation rules for ARF text files The rules for primary and foreign key validations of ARF (account based based) data files (version 2.0) are: i) ii) [ReportSerialNum] should be unique in Report file (ARFRPT.txt) [BranchRefNum] should be unique in Branch Data File (ARFBRC.txt)
11
Version 2.1
vii)
viii)
[ReportSerialNum + BranchRefNum + AccountNumber] should be unique in Account Data File (ARFACC.txt). All values of [ReportSerialNum] in ARFTRN.txt, ARFACC.txt, ARFINP.txt and ARFLPE.txt should have matching value in the Report file (ARFRPT.txt). All values of [BranchRefNum] in Account Data File (ARFACC.txt) should have a matching [BranchRefNum] value in Branch Data File (ARFBRC.txt) All values of [ReportSerialNum + BranchRefNum + AccountNumber] in Transaction Data File (ARFTRN.txt) should have matching [ReportSerialNum + BranchRefNum + AccountNumber] value in Account Data File (ARFACC.txt) All values of [ReportSerialNum + BranchRefNum + AccountNumber] in Individual Data File (ARFINP.txt) should have matching [ReportSerialNum + BranchRefNum + AccountNumber] value in Account Data File (ARFACC.txt) All values of [ReportSerialNum + BranchRefNum + AccountNumber] in Legal Person/Entity Data File (ARFLPE.txt) should have matching [ReportSerialNum + BranchRefNum + AccountNumber] value in Account Data File (ARFACC.txt)
5.1.1.3 XML Generation Rules for ARF text files The conversion rules for generation of XML reports from ARF (account based) text files are as under: i) ii) iii) The information in the single record in the Batch file (ARFBAT.txt) is populated in the elements ReportType, ReportingEntity, PrincipalOfficer, and BatchDetails of the XML report batch. The information about the data structure version from the Batch file (ARFBAT.txt) is populated in the element DataStructureVersion under the BatchHeader element. The utility automatically populates the elements GenerationUtilityVersion and DataSource from the Batch file (ARFBAT.txt). These elements may not be filled by the reporting entity directly generating the XML reports. Each record in the Report file (ARFRPT.txt) is used to create a Report element in the XML report batch. Within each Report the various data elements are generated as under The information from the relevant record in the Report file is populated in the elements ReportSerialNum, OriginalReportSerialNum and MainPersonName. In case of STR, the details of suspicion from Report file (ARFRPT.txt) with matching ReportSerialNum are populated in the SuspicionDetails element. Each record in the Account file (ARFACC.txt) with matching ReportSerialNum will create a new Account element within the Report. Within each Account, the various data elements are generated as under: o The details of the account from the Account file (ARFACC.txt) with matching ReportSerialNum are populated in the element AccountDetails. o The details of the branch linked to the account from the Branch file (ARFBRC.txt) with matching BranchRefNum are populated in the element Branch. o The details of the individuals related to the account from the Individual File (ARFINP.txt) with matching ReportSerialNum, BranchRefNum and AccountNumber are populated in the element PersonDetails. o The details of the legal persons/entities related to the account from the Legal Persons / Entities File (ARFLPE.txt) with matching ReportSerialNum, BranchRefNum and AccountNumber are populated in the element PersonDetails.
iv) v)
12
Version 2.1
vi)
The details of the transaction in the account from the Transaction File (ARFTRN.txt) with matching ReportSerialNum, BranchRefNum and AccountNumber are populated in the element Transaction. In case of generation of XML file from fixed width data files version 1.0, if enumerations are not categorised, the utility populates the value X /XX in the respective element. o
5.1.2
Generation of XML reports from TRF (transaction based) text files (v 2.0)
The rules for checking the data files and the conversion rules for generation of XML reports are given in following section. 5.1.2.1 Prerequisites for generation of XML from TRF text files The rules for checking TRF (transaction based) data files (version 2.0) are: i) ii) iii) iv) There should be seven data files with appropriate naming convention. The data files should be as per specified data structure and business rules. None of the mandatory fields should be left blank. All dates should be in YYYY-MM-DD format.
5.1.2.2 Key validation rules for TRF text files The rules for primary and foreign key validations of TRF (transaction based) data files (version 2.0) are: i) ii) iii) i) ii) [ReportSerialNum] should be unique in Report File (TRFRPT.txt). [InstitutionRefNum] should be unique in Branch Data File (TRFBRC.txt). All values of [ReportSerialNum] in TRFTRN.txt, TRFPIN.txt, TRFINP.txt and TRFLPE.txt should have matching value in TRFRPT.txt. All values of [TransactionInstitutionReferenceNum] in Transaction file should have a matching value in the Branch File (TRFBRC.txt). All values of ([IssueInstitutionRefNumber] + [InstrumentRefNumber]) in TRFPIN.txt should have matching value in relevant fields in TRFTRN.txt.
5.1.2.3 XML Generation Rules for TRF text files The conversion rules for generation of XML reports from TRF (transaction based) text files are as under: i) ii) iii) The information in the single record in the Batch file (TRFBAT.txt) is populated in the elements ReportType, ReportingEntity, PrincipalOfficer, and BatchDetails of the XML report batch. The information about the data structure version from the Batch file (TRFBAT.txt) is populated in the element DataStructureVersion under the BatchHeader element. The utility automatically populates the elements GenerationUtilityVersion and DataSource from the Batch file (TRFBAT.txt). These elements may not be filled by the reporting entity directly generating the XML reports. Each record in the Report file (TRFRPT.txt) is used to create a Report element in the XML report batch. Within each Report the various data elements are generated as under The information from the relevant record in the Report file (TRFRPT.txt) is populated in the elements ReportSerialNum, OriginalReportSerialNum and MainPersonName. In case of STR, the details of suspicion from Report file (TRFRPT.txt) with matching ReportSerialNum are populated in the SuspicionDetails element.
iv) v)
13
Version 2.1
vi)
Each record in the Transaction file (TRFTRN.txt) with matching ReportSerialNum will create a new Transaction element within the Report. The details about the institutions related to the transaction from the Branch file (TRFBRC.txt) with matching InstitutionRefNum are populated in the element Branch. The details about the payment instruments related to the transaction from the Payment Instruments file (TRFPIN.txt) with matching ReportSerialNum and InstrumentRefNum are populated in the element PaymentInstrument. The details about the individuals related to the transaction from the Individual Persons file (TRFINP.txt) with matching ReportSerialNum are populated in the elements RelatedPersons and Individual. The details about the legal persons/entities related to the transaction from the Legal Persons/Entities file (TRFLPE.txt) with matching ReportSerialNum are populated in the elements RelatedPersons and LegalPerson. In case of generation of XML file from fixed width data files version 1.0, if enumerations are not categorised, the utility populates the value X /XX in the respective element.
5.1.3
Generation of XML reports from CRF (counterfeit currency based) text files (v 2.0)
The rules for checking the data files and the conversion rules for generation of XML reports are given in following sections. 5.1.3.1 Prerequisites for generation of XML from CRF text files The rules for checking CRF (counterfeit currency based) data files (version 2.0) are: i) ii) iii) iv) There should be four data files with appropriate naming convention. The data files should be as per specified data structure and business rules. None of the mandatory fields should be left blank. All dates should be entered in YYYY-MM-DD format.
5.1.3.2 Key validation rules for CRF text files The rules for primary and foreign key validations of CRF (counterfeit currency based) data files (version 2.0) are: i) ii) iii) iv) [ReportSerialNum] should be unique in Report Data File (CRFRPT.txt). [BranchRefNum] should be unique in Branch Data File (CRFBRC.txt). All values of [BranchRefNum] in Report Data File (CRFRPT.txt) should have matching [BranchRefNum] value in Branch Data File (CRFBRC.txt). All values of [ReportSerialNum] in Transaction File (CRFTRN.txt) should have matching [ReportSerialNum] value in Report Data File (CRFRPT.txt).
5.1.3.3 XML Generation Rules for CRF (counterfeit currency based) text files The conversion rules for generation of XML reports from CRF (counterfeit currency based) text files are as under: i) ii) The information in the single record in the Batch file (CRFBAT.txt) is populated in the elements ReportType, ReportingEntity, PrincipalOfficer, and BatchDetails of the XML report batch. The information about the data structure version from the Batch file (CRFBAT.txt) is populated in the element DataStructureVersion under the BatchHeader element.
14
Version 2.1
iii)
iv) v)
vi)
The utility automatically populates the elements GenerationUtilityVersion and DataSource from the Batch file (CRFBAT.txt). These elements may not be filled by the reporting entity directly generating the XML reports. Each record in the Report file (CRFRPT.txt) is used to create a report element in the XML report batch. Within each report the various data elements are generated as under The information from the relevant record in the Report file (CRFRPT.txt) is populated in the elements ReportSerialNum and OriginalReportSerialNum. The details about the branch related to the incident from the Branch file (CRFBRC.txt) with matching BranchRefNum are populated in the element Branch. The details about the counterfeit currency related to the incident from the Report File (CRFRPT.txt) are populated in the element ReportSummary. The details about the fake notes from the Note Details file (CRFTRN.txt) with matching ReportSerialNum are populated in the TransactionDetails element. In case of generation of XML file from fixed width data files version 1.0, if enumerations are not categorised, the utility populates the value X /XX in the respective element.
5.1.4
The rules for checking the data files and the conversion rules for generation of XML reports from different variants of text files (v 1.0) are given in following section. Violation of these rules will lead to failure in generation of XML files. 5.1.4.1 Key validation rules for text files (v 1.0) for banks, insurance and intermediaries The rules for primary and foreign key validations of CTR/STR text files (version 1.0) for banks, insurance and intermediaries are: i) ii) iii) iv) v) vi) [Branch Reference Number] should be unique in Branch Data File (BRC) [Branch Reference Number + Account Number] should be unique in Account (ACC) Data File All values of [Branch Reference Number] in Account (ACC) Data File should have a matching [Branch Reference Number] value in Branch (BRC) Data File All values of [Branch Reference Number + Account Number] in Transaction (TRN) Data File should have matching [Branch Reference Number + Account Number] value in Account (ACC) Data File All values of [Branch Reference Number + Account Number] in Individual (INP) Data File should have matching [Branch Reference Number + Account Number] value in Account (ACC) Data File All values of [Branch Reference Number + Account Number] in Legal Person/Entity (LPE) Data File should have matching [Branch Reference Number + Account Number] value in Account (ACC) Data File
5.1.4.2 Key validation rules for text files (v 1.0) for authorised persons and payment systemoperators The rules for primary and foreign key validations of CTR/STR text files (version 1.0) for authorised persons and payment system operators are: i) ii) iii) [CTR/STR Reference Number] should be unique in Control File For each [CTR/STR Reference Number], the [Institution Reference Number] should be unique in Branch Data File All values of [CTR/STR Reference Number] in Transaction (TRN) Data File should have matching value in Control (CTL) File
15
Version 2.1
All values of [CTR/STR Reference Number] in Branch (BRC) Data File should have matching value in Control (CTL) File All values of [CTR/STR Reference Number] in Payment Instrument (PIN) Data File should have matching value in Control (CTL) File All values of [CTR/STR Reference Number] in Individual (INP) Data File should have matching value in Control (CTL) File All values of [CTR/STR Reference Number] in Legal Person/Entity Data (LPE) File should have matching value in Control (CTL) File
5.1.4.3 Key validation rules for CCR text files (v 1.0) The rules for primary and foreign key validations of CCR text files (version 1.0) are: i) ii) [Branch Reference Number] should be unique in Branch (BRC) Data File. All values of [Branch Reference Number] in Transaction (TRN) Data File should have matching [Branch Reference Number] value in Branch (BRC) Data File
5.2
The Report Validation Utility enables user to validate an XML report and prepares it for submission to FIU-IND. The broad features of the utility are: Perform schema validation (XSV) of XML file against the published schema (prescribed in XSD file) Perform preliminary rule validation (PRV) of XML file using rules (prescribed in the SCH file) View Data Quality Report (in XML format) generated by this utility or sent by FIU-IND Show the underlying data elements causing error if the original report is also linked to the utility Generate a draft revised report which is required to be resubmitted after correction. Generate a hash XML for the validated XML report Digitally sign the hash XML using the PFX or USB token option Configure the settings and preferences of the utility
5.3
The PDF based utility can be used by Reporting Entities to enter data of single reports. Detailed instructions have been provided in the pdf form to assist the users in filling the form and generate XML reports. The broad features of the utility are: Allow users to enter data in the pdf form Generate XML reports from captured data for submission through the secure FINnet Gateway Portal Allow import of data from saved XML file Allow printing of the report Allow saving of report data in the pdf form
The various types of Editable pdf based forms are given in section 4.3 of this document. The reporting entity must submit all reports to FIU-IND in XML form if it has the technical capability to do so.
16
Version 2.1
5.4
5.4.1
The Report Generation Utility enables user to generate XML report from various data sources. Refer section 5.1 of Reporting Format Guide for details. Refer the Report Generation Utility User Guide for further details on using the utility. 5.4.2 What is Report Validation Utility?
The Report Validation Utility enables user to validate an XML report and prepares it for submission to FIU-IND. Refer section 5.2 of Reporting Format Guide for details. Refer the Report Validation Utility User Guide for further details on using the utility. 5.4.3 What are the rules for generation of XML reports from variants of text files (v 1.0)?
The data files of different variants of text files (v 1.0) should comply with conversion rules for generation of XML reports. Violation of these rules will lead to failure in generation of XML files. Refer section 5.1.4 of Reporting Format Guide for details. 5.4.4 What are the prerequisites for generation of XML from text files?
The users should ensure that the fixed width text files should meet certain prerequisites before conversion to XML. Refer section 5.1.1.1, 5.1.2.1 and 5.1.3.1 of Reporting Format Guide for details about ARF, TRF and CRF respectively. 5.4.5 What are the key validation rules for text files?
The data in text files should comply with rules for primary and foreign key validations of text files (version 2.0). Refer section 5.1.1.2, 5.1.2.2 and 5.1.3.2 of Reporting Format Guide for details about ARF, TRF and CRF respectively. 5.4.6 What are the XML generation rules for text files?
The Report Generation Utility uses conversion rules for generation of XML reports from text files. Refer section 5.1.1.3, 5.1.2.3 and 5.1.3.3 of Reporting Format Guide for details about ARF, TRF and CRF respectively. 5.4.7 What codes can be used in element BranchRefNum to identify branches?
Reporting entities should use regulator issued/other unique codes to uniquely identify branches. In cases, where such codes are not available, reporting entities can use self generated branch codes to uniquely identify the branch.
17
Version 2.1
This section contains information related to submission of reports to FIU-IND and gives an overview of the FINnet Gateway Portal which has been developed as an interface for the reporting entities.
6.1
With the implementation of Project FINnet (Financial Intelligence Network) by FIU-IND in 2010, the primary mode of submission of reports to FIU-IND will be through the FINnet Gateway Portal. The FINnet Gateway Portal is designed as a comprehensive interface between the reporting entities and FIU-IND. The user guide for the FINnet Gateway Portal provides detailed documentation on using the portal. The broad features are: Login Page to allow access to registered users using credentials provided by the user. This page also has links to register a new user. Home page to display summary of actionable items (unread messages, pending reports, overdue reports etc.) and new content (Downloads, Discussions, FAQs, Events, Tips, Alerts and Surveys). Users module to view and manage the users of the reporting entity, FIU users and user groups. Profiles module to upload the digital certificate and manage the profile information of the reporting entity, principal officer and other users. Reports module with facility for web filing of reports and upload reports, view the upload history, rejected reports, reports where additional information is required and overdue reports. A report summary of reports submitted by the reporting entity is also provided. Messages module which is a messaging system between authorised users and FIU users. Resources module which is a comprehensive knowledge repository consisting of Downloads, FAQs, Problems and Solutions, Discussion Forums, Surveys, Events, Alerts and Tips.
6.2
Users of the reporting entities, who submit reports and exchange information with FIU-IND, have to register on the FINnet Gateway Portal. After registration, the authorized users will be provided credentials for login. The authorised users can upload the reports in prescribed XML format using the reports module of the FINnet Gateway Portal. Reporting entities should ensure that all errors detected by the utilities are rectified and the XML file is secured before uploading the reports. On successful upload, the portal will generate and display a unique Batch ID. The principal officer can attach digital signature using the Report Validation Utility prior to uploading the file. If the submitted batch is as per prescribed schema and if the file uploaded is signed with digital signature, the submission of the report will be treated as complete and the status of the batch will be Submitted. The date of submission of the batch will be the date of upload. If the file uploaded is without a digital signature, the portal would generate a single page Report Upload Confirmation (RUC) form. The principal officer would be required to print RUC form and post it to FIU-IND after signing. The signed copy of RUC form should be received by FIU-IND within 10 days of upload. After receipt of signed copy of RUC form, the date of upload would be taken as date of submission. If the RUC form is not received at FIU-IND within 10 days, it will be treated as non compliance with the reporting obligation. All reporting entities are encouraged to upload digitally signed reports.
18
Version 2.1
The description of the various status of Batch as displayed in the FINnet Gateway Portal is as under: Batch Status Uploaded Submitted Description On successful upload of the batch file, the status will be Uploaded. If the batch is as per prescribed schema and the batch has been uploaded with a digital signature, the status would be shown as Submitted. If the batch has been uploaded without digital signature, the status would be shown as Submitted after confirmation is received by FIU-IND. If the XML batch has been successfully uploaded without digital signature, the status would be shown as Submitted (AC) where AC means Awaiting confirmation. The reporting entity would be required to send a signed copy of report upload confirmation to FIU-IND within 10 days of upload. The status would be shown as Submitted after confirmation is received by FIU-IND. After validation of the batch and generation of Data Quality Report by FIU-IND the status of the batch changes from Submitted to Processed. The DQR will be available for download from the FINnet Gateway Portal.
Submitted (AC)
Processed
6.3
The reporting entities are required to submit prescribed reports using the FINnet Gateway Portal if they have technical capabilities to do so. The reporting entities can submit reports by sending the XML file on CD if: The reporting entity is not able to upload the report The reporting entity has been asked by FIU-IND to submit the report using CD
In case of submission on CD, following should be ensured: A label mentioning name of the Reporting Entity, unique identification code, type of report (CTR/STR/CCR/NTR), batch number, month and year of report should be affixed on each CD for the purpose of identification. Each CD should be accompanied by Summary of Reports duly signed by the principal officer. In case the size of data files exceeds the capacity of one CD, the data files should be compressed by using Winzip 8.1 or ZipItFast 3.0 (or higher version) compression utility only to ensure quick and smooth acceptance of the file. The CD should be virus free.
6.4
Reporting Entities are expected to submit reports in electronic form. However if the reporting entity does not have the capability to generate report in electronic form, reports may be submitted in manual paper-based forms. Reporting Entities should use the FIU-IND provided PDF Form based utilities to capture data and print the report as per the specified format. The paper based report should be duly signed by the Principal Officer and posted to FIUIND. However, Reporting Entities should make all reasonable efforts to send reports in electronic rather than the paper based format.
19
Version 2.1
6.5
6.5.1
With the implementation of Project FINnet (Financial Intelligence Network) by FIU-IND in 2010, the primary mode of submission of reports to FIU-IND will be through the FINnet Gateway Portal. The FINnet Gateway Portal is designed as a comprehensive interface between the reporting entities and FIU-IND. Refer section 6.1 of Reporting Format Guide for details. Refer the FINnet Gateway User Guide for further details on using the utility. 6.5.2 How can reports be submitted over the FINnet Gateway?
All users of the reporting entities have to register on the FINnet Gateway Portal. After registration, the authorised users will be given credentials for login. The authorised users can upload the reports in prescribed XML reports using the reports module of the FINnet Gateway Portal. Reporting entities should ensure that all errors detected by the utilities are rectified and the XML converted to a Hash XML which can further be digitally signed using the PFX or USB token option prior to upload. On successful upload, the portal shall generate and display a unique Batch ID. 6.5.3 What are the different modes of report submission?
Reporting entities should submit reports online through FINnet Gateway portal. However, in certain cases they can submit reports by sending the XML file on CD or paper based reports using editable PDF forms provided by FIUIND. 6.5.4 What is the procedure for submitting reports using digital signature?
The principal officer can attach the digital signature using the Report Validation Utility provided by FIU-IND. The validated XML file which is error free is converted to a Hash XML using the Secure XML tab. Subsequently, users can use the PFX or USB token and digitally sign prior to uploading the file. If the submitted batch is as per prescribed schema and if the file uploaded is digitally signed, the submission of the report will be treated as complete and the status of the batch will be Submitted. 6.5.5 What is the procedure for submitting reports without using digital signature?
The validated XML file should be converted to Hash XML using the Secure XML tab in Report Validation Utility provided by FIU-IND. When the Hash XML file is uploaded without digital signature, the FINnet Gateway portal would generate a single page report upload confirmation (RUC) form. The principal officer would be required to print the RUC form and post it to FIU-IND after signing. The signed copy of the RUC form should be received by FIU-IND within 10 days of upload. After confirmation, the date of upload would be taken as date of submission. If the RUC form is not received at FIU-IND within 10 days, it will be treated as non compliance with the reporting obligation. All reporting entities are encouraged to upload reports with digital signature. 6.5.6 What is batch number?
Reporting Entities should maintain a unique series of numbers to be used as batch number. Refer section 11.1.5 of Reporting Format Guide for details. 6.5.7 What is batch ID?
Batch ID is the unique acknowledgement number for each batch generated on its successful upload.
20
Version 2.1
6.5.8
As the batch is submitted and processed by FIU-IND, the status of the batch changes from Uploaded to Submitted or Submitted (AC) and Processed. Refer section 6.2 of Reporting Format Guide for details. 6.5.9 Can reports be submitted on CDs?
The reporting entities are required to submit prescribed reports using the FINnet Gateway Portal if they have technical capabilities to do so. The reporting entities can submit reports by sending the XML file on CD if the reporting entity is not able to upload the report. In some cases, FIU-IND may ask reporting entity to submit the report using CD 6.5.10 Can reports be submitted in manual reporting formats? Manual Reporting Formats have been specified as editable PDF forms which can be used by reporting entities to print the report and submit as a paper based report. The editable PDF form based utility enables users to enter or import data, validate for errors and generate XML reports for submission through the secure FINnet Gateway Portal. Alternately, reporting entities can print the report in OCR compatible format and post the paper based report to FIU-IND. The reporting entity must submit all reports to FIU-IND in XML format specifications if it has the technical capability to do so. Refer section 4.3 of Reporting Format Guide for details.
21
Version 2.1
This section explains the integrated XML Schema validation and Rule based validation approach adopted by FIUIND. The section also gives an overview of the validation rules, types of errors, Data Quality Report and error resolution steps.
7.1
Types of validation
The data quality validation has been enhanced by introducing multiple levels of validation covering both XML Schema validation and Rule based validation. The XML file will undergo following three types of validations: XML Schema Validation (XSV): Verification of XML file against the published schema (XSD file) Preliminary Rule Validation (PRV): Preliminary verification of XML file using rules which can be prevalidated before submission. These rules would be specified in external rules file (SCH file) shared with reporting entities. Advanced Rule Validation (ARV): Verification of XML files using rules which require additional information such as earlier submitted report, external data sources or dictionaries.
7.2
Types of Errors
The types of errors found in the report have been categorised into schema error, fatal error, non fatal error and probable error. The description of error type and its resolution is as under: Error Type Schema error Error Description Error Resolution
Errors in XML file on account of validation The errors have to be resolved in XML file to enable against the XML schema (xsd) schema validation by utility Errors in XML file which would result in rejection of report A batch containing fatal errors will be allowed to be uploaded but reports with fatal errors will be rejected. The reporting entity would be required to resubmit revised reports after resolving fatal errors No requirement to submit a revised report. These errors are taken into account to compute data quality rating. The errors may be resolved in future submissions These are not confirmed errors. The reporting entity would be required to verify and submit revised report only if error is confirmed
Fatal error
Errors in XML file which will not lead to rejection of reports Errors in XML file which will not lead to rejection of reports
Probable error
7.3
The following table shows relationships between validation type and error types: Validation Type XML Schema Validation (XSV) Preliminary Rule Validation (PRV) Advanced Rule Validation (ARV) Schema error Fatal error Non fatal error Probable error
22
Version 2.1
7.4
An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself. These constraints are generally expressed using some combination of grammatical rules governing the order of elements, Boolean predicates that the content must satisfy, data types governing the content of elements and attributes, and more specialized rules such as uniqueness and referential integrity constraints. The process of checking to see if an XML document conforms to a schema is called validation, which is separate from XML's core concept of syntactic well-formedness. All XML documents must be well-formed, but it is not required that a document be valid unless the XML parser is "validating," in which case the document is also checked for conformance with its associated schema.
7.5
Preliminary Rule Validation (PRV) is preliminary verification of XML file using rules which can be pre-validated before submission. These rules would be specified in external rules file (SCH file) shared with reporting entities. The description of rules for Preliminary Rule Validation (PRV) is as under: S. No. Validation Rule 1 2 3 4 MandatoryValueFatal MandatoryValueNonFatal UniqueValue SufficiencyElementFatal Rule Description The element should not be blank The element should not be blank Example Error Type
Address of person should Fatal error not be blank PAN of person should not Non fatal error be blank Fatal error
The value of element in multiple ReportSerialNum in a records should be unique batch should be unique At least one element should be present At least one element should be present The data element should be of sufficient length The data element should be of sufficient length The value should be equal to the sum of value of data elements The value should be greater or less than the value of data element
At least one account Fatal error holder should be included At least one individual for the account should be included The ID number should exceed 5 characters The address should exceed 8 characters Non fatal error
SufficiencyElementNonFatal
6 7
SufficiencyLengthFatal SufficiencyLengthNonFatal
ConsistencySum
The total amount matches with the sum of Fatal error transaction amounts in the report The sum of transactions during the month should not be greater than the Non fatal error sum of transactions during the year If the transaction value is same as the account number, the error Probable Error
ConsistencyValue
10
ErrorProbablityHigh
23
Version 2.1
Rule Description
Error Type
11
ErrorProbablityMedium
If the value of a single cash transaction exceeds Probable Error 1billion INR, the error probability is medium If there are multiple transactions of the same Probable Error value on the same day, the error probability is low
12
ErrorProbablityLow
Sample application of preliminary validation rules for the three reporting formats is given in Annexure A.3, B.3 and C.3 of this document.
7.6
Advanced Rule Validation (ARV) is verification of XML files using rules which require additional information such as earlier submitted report, external data sources or dictionaries. The description of some rules for Advanced Rule Validation (ARV) is as under: S. No. 1 Validation Rule SufficiencyValue Rule Description The data element should contain sufficient information The value should be consistent with earlier report Example The address should contain sufficient information (dictionary based) Error Type Non fatal error
ConsistencyValueEarlierReport
The cumulative credit amount in the year should not be lower Non fatal error than the report of the previous month in the same year The pincode of the customer should match with the pincode Non fatal error dictionary The PAN of the customer should be a valid PAN in Income Tax Database Non fatal error
The value should be consistent with internal ConsistencyValueInternalSource data source maintained at FIU The value should be ConsistencyValueExternalSource consistent with external data source
Sample application of advanced validation rules for the three reporting formats is given in Annexure A.3, B.3 and C.3 of this document.
24
Version 2.1
7.7
On successful file upload, FIU-IND shall subject the reports to different levels of validations. On completion of validations, FIU-IND shall generate a Data Quality Rating for the batch which is an indicator/measure of the quality of reports in a batch submitted to FIU-IND. The data quality rating would be communicated to the reporting entity after each successful upload and validation. The description of data quality rating is as under: Data Quality Rating A B C D X Description The batch of reports contains no fatal or non fatal errors The batch of reports has no fatal errors but only non fatal errors Few reports (< 50%) in the batch have been rejected due to fatal errors Large number of reports (>= 50%) in the batch have been rejected due to fatal errors The batch has not been rated
7.8
The Data Quality Report contains summary level details, statistics and details of errors/warnings. The Data Quality Report states the quality of the report and indicates if the report is acceptable, requires resubmission or has warnings for future quality improvement. The DQR will be available for download in XML format against each report batch. DQR downloaded in XML format can be viewed using the Report Validation Utility or any other XML editor. The explanation of schema of the Data Quality Report is provided in Annexure D of this document. The DQR has separate sections for report summary information, acknowledgement information and error details for preliminary validation and advanced validation. The error details describe the validation rule that was violated, the data element in which the error occurred and the path of the element in the original XML report file. Reporting Entities can link the downloaded DQR in XML format to the original report submitted using the Report Validation Utility. The DQR provides the path and the data element in which the error occurred. The Report Validation Utility can also be used to import the original report and view using the error report.
7.9
Resolution of errors
Reporting Entities should use the DQR to examine the data quality errors. Reports that have fatal errors need to be rectified and resubmitted. Reporting Entities should take necessary steps to rectify the error at source so that the same errors are not repeated. Non-fatal errors are errors that are warning in nature. Reporting Entities need not resubmit the reports containing non-fatal errors. Reporting Entities should take necessary action to rectify such errors at source so that they do not recur. Reporting Entities should take necessary steps to ensure that the quality of the data submitted improves progressively over time.
25
Version 2.1
Preliminary Rule Validation (PRV): Preliminary verification of XML file using rules which can be prevalidated before submission. These rules would be specified in external rules file (SCH file) shared with reporting entities. Advanced Rule Validation (ARV): Verification of XML files using rules which require additional information such as earlier submitted report, external data sources or dictionaries.
7.10.2 What are the types of errors checked during data quality validation? The types of errors found in the report have been categorised into schema error, fatal error, non fatal error and probable error. Refer section 7.2 of Reporting Format Guide for details. 7.10.3 What is XML Schema Validation (XSV)? An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself. The process of checking to see if an XML document conforms to a schema is called validation. 7.10.4 What is Preliminary Rule Validation (PRV)? Preliminary Rule Validation (PRV) is preliminary verification of XML file using rules which can be pre-validated before submission. These rules would be specified in external rules file (SCH file) shared with reporting entities. The external files used for validation are schematron rules. Refer section 7.5 of Reporting Format Guide for details. 7.10.5 What is Advanced Rule Validation (ARV)? Advanced Rule Validation (ARV) is verification of XML files using rules which require additional information such as earlier submitted report, external data sources or dictionaries. Refer section 7.6 of Reporting Format Guide for details. 7.10.6 What is Data Quality Rating? On successful file upload, FIU-IND shall subject the reports to different levels of validations. On completion of validations, FIU-IND shall generate a Data Quality Rating for the batch which is an indicator/measure of the quality of reports in a batch submitted to FIU-IND. The data quality rating would be communicated to the reporting entity after each successful upload and validation. Refer section 7.7 of Reporting Format Guide for details. 7.10.7 What is Data Quality Report? The Data Quality Report contains summary level details, statistics and details of errors/warnings. The Data Quality Report states the quality of the report and indicates if the report is acceptable, requires resubmission or has warnings for future quality improvement. The DQR will be available for download in XML format against each report batch. Refer section 7.8 of Reporting Format Guide for details. 7.10.8 How should Reporting Entities resolve errors? Reporting Entities should use the DQR to examine the data quality errors. Reports that have fatal errors need to be rectified and resubmitted. Reporting Entities should take necessary steps to rectify the error at source so that the same errors are not repeated. Non-fatal errors are errors that are warning in nature. Reporting Entities need not resubmit the reports containing non-fatal errors. Reporting Entities should take necessary action to rectify such errors at source so that they do not recur. Reporting Entities should take necessary steps to ensure that the quality of the data submitted improves progressively over time.
26
Version 2.1
This section contains information about modification of an earlier submitted report which could be on account of resubmission of rejected report (due to fatal errors), providing additional information to an earlier submitted report or replacement of an incorrect report (data omitted or wrong data submitted in the original report).
8.1
Rejection of reports
If the report batch submitted by the reporting entities has reports with fatal errors, such reports would be rejected. The list of all uploaded reports can be viewed on the FINnet Gateway in the section Reports > Uploaded reports. For each batch, the number of reports in the batch which have been rejected due to fatal errors would be displayed as Reports Rejected. The reporting entity is required to resubmit the rejected reports after corrections. The list of all batches where reports have been rejected would be separately displayed in the section Reports > Rejected reports. If the reporting entity submits a replacement batch after removing the errors, the details of rejected reports would be updated after processing. The reporting entity can access following details about rejected reports on the FINnet Gateway: Information Field Report Type Submission Date Batch Type Description CTR, STR, CCR, NTR Date of successful upload Batch Type having following values: Batch ID Report Month Batch Status N- New report R- Replacement report D- Deletion report
Unique number generated for the batch Month and year of the report (in case of monthly reporting) Status of batch having following values: Uploaded Submitted Submitted (AC)- Awaiting Confirmation Processed
Reports in Batch Reports Rejected (initial) Reports Rejected (current) Fatal Errors (current) Download DQR
Total number of reports in the batch Number of reports in the batch which were rejected in the original batch due to fatal errors Number of rejected reports in the batch which have not been rectified till date Number of fatal errors in the batch which have not been rectified till date Link to download the Data Quality Report in XML format
8.2
The Data Quality Report would contain information about reports in the batch which have been rejected along with details of the fatal error. The Report Validation Utility can be used to link the Data Quality Report to the submitted batch to extract the rejected reports in a separate batch. The reporting entity is required to rectify the errors in the extracted rejected reports and upload it as a replacement batch. Financial Intelligence Unit India (FIU-IND)
27
Version 2.1
8.3
If the reporting entity wants to submit additional information in relation to a previously submitted report, a replacement report with complete information needs to be submitted. This submission could be to resolve a nonfatal error or in response to a request from FIU-IND. Refer to section 9.1 for additional information.
8.4
If the reporting entity comes to know that data was omitted in original report or part of the data was wrongly submitted, a replacement report needs to be submitted to modify a previously submitted report.
8.5
If the reporting entity comes to know that wrong data has been submitted in original report, a deletion report needs to be submitted to delete a previously submitted report. However the entire report information needs to be resubmitted in the batch to ensure that such deletion is not being requested by an unauthorised person.
8.6
As mentioned Reporting Entities would like to modify a previously report in following cases:
A separate batch has to be submitted where such resubmission is made and the batch should contain only one type of report. The reporting entity should also provide batch level information in the element Batch/BatchDetails. The information about report which has to be replaced or deleted is provided in the element Batch/Report. Both these elements are explained in following sections. 8.6.1 Batch Details
The element Batchdetails provides information about the batch including BatchType, OriginalBatchId and ReasonOfRevision. The details of the element are given in the Annxure A.1 of this document. The relevant information in the element is as under: Element Description Unique number of the Batch given by the reporting entity.Reporting Entities should maintain a unique series of numbers to be used as Batch Number. After successful submission of the batch to FIU, a new unique BatchID will be allotted for future reference. The reporting entities should maintain the linkage between the BatchNumber and BatchID. Date of preparation of the batch in YYYY-MM-DD The month to which the report pertains to (in case of monthly reporting obligations such as CTR). Month should be as per Gregorian calendar in the format 01, 02 etc. NA should be used for reports which do not have monthly reporting obligations (STR etc.). Refer section 11.1.5.1 for further details on enumerations. Length Mandatory
BatchNumber
11
Yes
BatchDate
10
Yes
MonthOfReport
Yes
28
Version 2.1
Element
Description The year to which the report pertains to (in case of monthly reporting obligations such as CTR). Year should be as per Gregorian calendar in the format 2010, 2011 etc. NA should be used for reports which do not have monthly reporting obligations (STR etc.). Refer section 11.1.5.2 for further details on enumerations. Mode of operation of the batch. Permissible values are: P - Production Mode T - Test Mode Refer section 11.1.5.3 for further details on enumerations. Type of Batch submitted. Permissible values are: N - New Report R - Replacement Report D - Deletion Report One batch can contain only one type of batch and one type of report. If reports in the batches are being submitted to remove errors or after including additional information, the complete report needs to be resubmitted as a replacement report. Refer section 11.1.5.4 for further details on enumerations. BatchId of the original batch which is being replaced deleted or referred by reports in the current batch. In case the batch is new and unrelated to any previous batch, mention 0 here. Reason for revision when the original batch is replaced or deleted. Permissible values are: A - Acknowledgement of original batch had many fatal, non fatal or probable errors which are being resolved B - Operational errors in original batch have been identified and reports are being revised or deleted sou moto C - The replacement report is on account of additional information being submitted N - Not applicable as this is a new batch Z - Other reason Refer section 11.1.5.5 for further details on enumerations. PKI certificate number. This element is used when a digital certificate is used to authenticate the report.
Length
Mandatory
YearOfReport
Yes
OperationalMode
Yes
BatchType
Yes
OriginalBatchID
10
Yes
ReasonOfRevision
Yes
PKICertificateNum
10
No
29
Version 2.1
8.6.2
Report details
Batch/Report provides details of the Reports in the batch. This element has been defined differently for each of the reporting format in Annexure A.1, B.1 and C.1 of this document. However the elements ReportSerialNum and OriginalReportSerialNum are common in all reporting formats which are defined as under: Element ReportSerialNum Description The report serial number should be unique within a batch. Indicates the report serial number of the original report that has to be replaced or deleted. In case the report is new and unrelated to any previous report, mention 0 here. Length 8 Mandatory Yes
OriginalReportSerialNum
Yes
8.7
8.7.1
The list of all uploaded reports can be viewed on the FINnet Gateway in the section Reports > Uploaded reports. 8.7.2 When do reports get rejected?
If the report batch submitted by the reporting entities has reports with fatal errors, such reports would be rejected. 8.7.3 How can rejected reports be viewed?
The list of all batches where reports have been rejected would be separately displayed in the section Reports > Rejected reports. If the reporting entity submits a replacement batch after removing the errors, the details of rejected reports would be updated after processing. Refer section 8.1 of Reporting Format Guide for details. 8.7.4 How can an incorrect report be modified?
If the reporting entity comes to know that data was omitted in original report or part of the data was wrongly submitted, a replacement report needs to be submitted to modify a previously submitted report. 8.7.5 How can the rejected reports be segregated for resubmission?
The Data Quality Report would contain information about reports in the batch which have been rejected along with details of the fatal error. The Report Validation Utility can be used to link the Data Quality Report to the submitted batch to extract the rejected reports in a separate batch. The reporting entity is required to rectify the errors in the extracted rejected reports and upload it as a replacement batch. 8.7.6 How can an incorrect report be deleted?
If the reporting entity comes to know that wrong data has been submitted in original report, a deletion report needs to be submitted to delete a previously submitted report. However the entire report information needs to be resubmitted in the batch to ensure that such deletion is not being requested by an unauthorised person.
30
Version 2.1
This section explains submission of additional information or documents related to a previously submitted report. Such a submission could be suo moto or in response to a request by FIU-IND. The reporting entity may need to submit additional information related to a previously submitted report in following cases: Additional information is needed by FIU-IND for analysis Additional document is needed by FIU-IND for analysis The reporting entity wants to suo moto submit additional document to support grounds of suspicion
Submission of additional information related to earlier submitted report is explained in following sections.
9.1
If additional information related to the submitted report is required for analysis, an information request will be generated in XML format and communicated to the reporting entity using the FINnet Gateway. The information requests will be displayed under the section Reports > Additional Information Required. The reporting entity would be required to submit the information as replacement report.
9.2
If additional documents such as KYC document related to the submitted report is required for analysis, an information request will also be generated in XML format and communicated to the reporting entity using the FINnet Gateway under the section Reports > Additional Information Required. If all additional information requested in a batch has been received, the request will be closed.
9.3
If reporting entity intends to submit additional documents such as KYC document, copy of instrument etc to support grounds of suspicion, they are required to indicate Y in the element AdditionalDocuments in the element Batch/Report/SuspicionDetails. In such cases, an information request will be generated in XML format and communicated to the reporting entity using the FINnet Gateway under the section Reports > Additional Information Required. The reporting entity would submit documents in a manner similar to request based submission of additional documents.
9.4
9.4.1
The reporting entity may need to submit additional information related to a previously submitted report in following cases: 9.4.2 Additional information is needed by FIU-IND for analysis Additional document is needed by FIU-IND for analysis The reporting entity wants to suo moto submit additional document to support grounds of suspicion What is request based submission of additional information?
If additional information related to the submitted report is required for analysis, an information request will be generated in XML format and communicated to the reporting entity using the FINnet Gateway. The information requests will be displayed under the section Reports > Additional Information Required. The reporting entity would be required to submit the information as replacement report.
31
Version 2.1
9.4.3
If additional documents such as KYC document related to the submitted report is required for analysis, an information request will also be generated in XML format and communicated to the reporting entity using the FINnet Gateway under the section Reports > Additional Information Required. If all additional information requested in a batch has been received, the request will be closed. 9.4.4 What is suo moto submission of additional documents?
If reporting entity intends to submit additional documents such as KYC document, copy of instrument etc to support grounds of suspicion, they are required to indicate Y in the element AdditionalDocuments in the element Batch/Report/SuspicionDetails. In such cases, an information request will be generated in XML format and communicated to the reporting entity using the FINnet Gateway under the section Reports > Additional Information Required. The reporting entity would submit documents in a manner similar to request based submission of additional documents.
32
Version 2.1
Editable PDF forms Cash Transaction Report (Account Based) Cash Transaction Report (Transaction Based) Suspicious Transaction Report (Account Based) Suspicious Transaction Report (Transaction Based) Counterfeit Currency Report
33
Version 2.1
Table: Details of Batch Element Description Type of report in the batch. Permissible values are: CTR - Cash Transaction Report STR - Suspicious Transaction Report NTR - NPO Transaction Report One batch can contain only one prescribed type of report. Refer section 11.1.1.1 for further details on enumerations. Type of reporting format in the batch. Permissible values are: ARF Account based reporting format One batch can contain only one prescribed type of reporting format. Refer section 11.1.1.2 for further details on enumerations. BatchHeader ReportingEntity Details of the Batch Type and other version information. Refer section 11.1.2 for details. Details of the Reporting Entity. Refer section 11.1.3 for details. Section 11.1.2 Section 11.1.3 Yes Yes Length Mandatory
ReportType
Yes
ReportFormatType
Yes
34
Version 2.1
Description Details of the Principal Officer. Refer section 11.1.4 for details. Details of the Batch of reports. Refer section 11.1.5 for details. Details of Reports in the batch. Refer section 11.1.6 for details.
11.1.1.1 Enumeration for ReportType Report Type describes type of prescribed reports in the batch. One batch can contain only one prescribed type of report. Code Description Remarks Contains information related to (a) All cash transactions of the value of more than rupees ten lakhs or its equivalent in foreign currency; (b) All series of cash transactions integrally connected to each other which have been valued below rupees ten lakhs or its equivalent in foreign currency where such series of transactions have taken place within a month. Contains information related to Suspicious transactions. Suspicious 1 transaction means a transaction referred to in clause (h) , including an attempted transaction, whether or not made in cash which, to a person acting in good faith (a) gives rise to a reasonable ground of suspicion that it may involve proceeds of an offence specified in the Schedule to the Act, regardless of the value involved; or (b) appears to be made in circumstances of unusual or unjustified complexity; or (c) appears to have no economic rationale or bonafide purpose; or (d) gives rise to a reasonable ground of suspicion that it may involve financing of the activities related to terrorism. (NPO) Contains information related to transactions involving receipts by non-profit organisations of value more than rupees ten lakh, or its equivalent in foreign currency.
STR
NTR
11.1.1.2 Enumeration for ReportFormatType Report Format Type describes type of reporting format in the batch. One batch can contain only one prescribed type of reporting format. Code Description ARF Account based reporting format TRF CRF Transaction based reporting format Remarks Account based reporting format (ARF) for reporting of account based CTRs, STRs and NTRs Transactions based reporting format (TRF) for reporting of transaction based CTRs, STRs and NTRs
Counterfeit currency based reporting CCR reporting format (CRF) for reporting of counterfeit currency format reports (CCRs)
35
Version 2.1
11.1.2 element Batch/BatchHeader BatchHeader contains information about the types of reports in the batch and version information. Figure: Overview of BatchHeader
Table: Details of BatchHeader Element Description Version of the data structure used for generation of XML file. Permissible values are: 1 - Version 1.0 2 - Version 2.0 This value will be populated by the Report Generation Utility during report generation. The value may be set to 2 if reporting entities are directly creating XML file. Refer section 11.1.2.1 for further details on enumerations. Version of the Report Generation Utility which has generated the XML file. This value will be populated by the Report Generation GenerationUtilityVersion Utility and need not be filled by reporting entities not using Report Generation Utility. Source of Data for XML file. Permissible values are: pdf - Generated from editable pdf form rgu - Direct data entry in Report Generation Utility txt - Generated from Text file xml Direct generation of XML file This value will be populated by the utilities developed by FIUIND. The value should be set to xml if reporting entities are directly creating XML file. Refer section 11.1.2.2 for further details on enumerations. Financial Intelligence Unit India (FIU-IND) 5 No Length Mandatory
DataStructureVersion
Yes
DataSource
Yes
36
Version 2.1
11.1.2.1 Enumeration for DataStructureVersion DataStructureVersion describes version of the data structure used for generation of XML file. This value will be populated by the Report Generation Utility during report generation. Code Description 1 2 Version 1.0 Version 2.0 Remarks When the XML file is generated using text files version 1.0 When the XML file is generated using text files version 2.0. The value may be set to 2 if reporting entities are directly creating XML file
11.1.2.2 Enumeration for DataSource DataSource describes source of data capture in the Report Generation Utility. This value will be populated by the utilities developed by FIU-IND. The value may be set to XML if reporting entities are directly creating XML file. Code Description pdf rgu txt xml PDF file RGU file Text file XML file Remarks When the XML file is generated using PDF Form based utility When the XML file is generated by direct data entry in the utility When the XML file is generated from fixed width text file When the XML is generated by reporting entities directly
37
Version 2.1
11.1.3 element Batch/ReportingEntity ReportingEntity contains information about the reporting entity which is submitting the report batch. Figure: Overview of ReportingEntity
Element ReportingEntityName
Table: Details of ReportingEntity Description Complete name of the reporting entity (Bank, financial institution, intermediary). The category to which the Reporting entity belongs.
Length 80
Mandatory Yes
ReportingEntityCategory
FIU has provided a five digit category code to specify the category of the reporting entity. Example: BAPUB for Public Sector banks. Refer section 11.1.3.1 for details on enumerations. Any unique number for the Reporting Entity. This number can be the registration number or any number used in correspondence with the regulator. This number will be used during verification of the registration of the reporting entity and in correspondence with the regulators. If the regulator has not issued any number, the reporting entity may use any other self generated number.
Yes
RERegistrationNum
12
No
38
Version 2.1
Element
Description Unique ID issued by FIU. FIU will communicate the FIUREID during the registration of the reporting entity on the FINnet Gateway Portal. The FIUREID will be in the fomat XXXXXNNNNN where XXXXX is generated in accordance with section 11.1.3.1 and NNNNN is a sequentially generated numder. Use XXXXXNNNNN till the ID is communicated.
Length
Mandatory
FIUREID
10
Yes
11.1.3.1 Enumeration for ReportingEntityCategory FIU has provided following five digit category code to specify the category of the reporting entity. S. No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Category Code BAPUB BAPVT BAFOR BARRB BALAB BASUC BANUC BASCO BADCB BAOTH FIINL FIINN FIHFC FIAD1 FIAD2 FIAD3 FIFFM FIMTP FIMTA FICSO FICCP FIAFI FIHPC Reporting Entity Category Description Public Sector Banks Private Sector Banks Foreign Banks Regional Rural Banks Local Area Banks Scheduled Urban Cooperative Banks Non Scheduled Urban Cooperative Banks State Cooperative Banks District Cooperative Banks Other Banking Companies Life Insurance Companies Non Life Insurance Companies Housing Finance Companies Authorised Dealer Category I Authorised Dealer Category II Authorised Dealer Category III Full Fledged Money Changer (FFMC) Money Transfer Service Principal Money Transfer Service Agent Card System Operators Central Counter Party All India Financial Institutions Hire Purchase Companies Prefix for REID BASCB BASCB BASCB BARRB BALAB BAUCB BAUCB BASCO BADCB BAOTH FIINL FIINN FIHFC FIAPR FIAPR FIAPR FIAPR FIMTP FIMTA FICSO FICCP FIAFI FIHPC
39
Version 2.1
S. No. 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
Category Code FICFC FINBA FINBN FIOTH CASIN INCOL INDEP INDPP INBRO INBDS INSTA INRTA INMER INUND INBAN INREG INPOM INADV INTRU INCRE INVCD INCUS INFII INVCF INCOM INSBR INOTH RGRBI ZZZZZ XXXXX
Reporting Entity Category Description Chit Fund Companies NBFC Accepting Deposits NBFC not Accepting Deposits Other Financial Institutions Casinos Collective Investment or MF Schemes Depositories Depository Participants Share Brokers Derivative Members Share Transfer Agents Registrars and Transfer Agents Merchant Bankers Underwriters Bankers to an Issue Registrars to Issue Portfolio Managers Investment Advisors Trustees to Trust Deeds Credit Rating Agencies Domestic Venture Capital Funds Custodian of Securities Foreign Institutional Investors Foreign Venture Capital Funds Commodity Broker Sub Brokers Other Intermediaries Regulators - Reserve Bank of India Others Not Categorised
Prefix for REID FICFC FINBF FINBF FIOTH CASIN INCOL INDEP INDPP INBRO INBDS INSTA INRTA INMER INUND INBAN INREG INPOM INADV INTRU INCRE INVCD INCUS INFII INVCF INCOM INSBR INOTH RGRBI ZZZZZ
40
Version 2.1
11.1.4 element Batch/PrincipalOfficer PrincipalOfficer describes the information about the principal officer of the reporting entity. Figure: Overview of Principal Officer
Table: Details of Principal Officer Element POName PODesignation Example General Manager. Details of the Principal Officers Address. POAddress Refer section 11.1.4.1 for details about the common type Address. Details of the Principal Officers Mobile phone number. POPhone POemail Refer section 11.1.4.2 for details about the common type Phone. Principal Officers email address. Section 11.1.4.2 50 Yes No Section 11.1.4.1 Yes Description Principal Officers Name. Principal Officers Designation. 80 Yes Length 80 Mandatory Yes
41
Version 2.1
Table: Details of Address Element Address City Description Complete address consisting of house number, building name, street, locality, city, state, country and pincode (optional). Name of City/Town State code that identifies the State. StateCode The two digit state code has to be mentioned as per Indian Motor Vehicle Act 1988. Refer Annexure E for State codes. If state code is not available, use XX. Pin Code that identifies the locality. PinCode In case of India, the 6 digit Pin code as per India Posts has to be mentioned. In case of countries outside India, respective code may be used. If Pin code is not available, use XXXXXX. Country code that identifies the country. CountryCode The Country Code as per ISO 3166 has to be mentioned. Refer Annexure F for Country codes. Use IN for India. If CountryCode is not available, use XX. 2 Yes 10 No 2 Yes Length 225 50 Mandatory Yes No
42
Version 2.1
Table: Details of Phone Element Telephone Mobile Fax Description Telephone number in format STD Code-Telephone number. Contact Mobile number. Fax number in format STD Code-Telephone number. Length 30 30 30 Mandatory No No No
11.1.5 element Batch/BatchDetails BatchDetails contains information such as BatchNumber, BatchDate, MonthOfReport, BatchType etc. Figure: Overview of BatchDetails
43
Version 2.1
Table: Details of BatchDetails Element Description Unique number of the Batch given by the reporting entity. BatchNumber Reporting Entities should maintain a unique series of numbers to be used as Batch Number. After successful submission of the batch to FIU, a new unique BatchID will be allotted for future reference. The reporting entities should maintain the linkage between the BatchNumber and BatchID. Date of preparation of the batch in YYYY-MM-DD The month to which the report pertains to (in case of monthly reporting obligations such as CTR). MonthOfReport Month should be as per Gregorian calendar in the format 01, 02 etc. NA should be used for reports which do not have monthly reporting obligations (STR etc.). Refer section 11.1.5.1 for further details on enumerations. The year to which the report pertains to (in case of monthly reporting obligations such as CTR). YearOfReport Year should be as per Gregorian calendar in the format 2010, 2011 etc. NA should be used for reports which do not have monthly reporting obligations (STR etc.). Refer section 11.1.5.2 for further details on enumerations. Mode of operation of the batch. OperationalMode Permissible values are: P - Production Mode T - Test Mode Refer section 11.1.5.3 for further details on enumerations. Type of Batch submitted. Permissible values are: N - New Report R - Replacement Report D - Deletion Report BatchType One batch can contain only one type of batch and one type of report. If reports in the batches are being submitted to remove errors or after including additional information, the complete report needs to be resubmitted as a replacement report. Refer section 11.1.5.4 for further details on enumerations. BatchID of the original batch which is being replaced deleted or referred by reports in the current batch. OriginalBatchID In case the batch is new and unrelated to any previous batch, mention 0 here. 10 Yes 1 Yes 1 Yes 4 Yes 2 Yes 11 Yes Length Mandatory
BatchDate
10
Yes
44
Version 2.1
Element
Description Reason for revision to be stated when the original batch is replaced or deleted.
Length
Mandatory
Permissible values are: A - Acknowledgement of original batch had many fatal, non fatal or probable errors which are being resolved B - Operational errors in original batch have been ReasonOfRevision identified and reports are being revised or deleted suo moto C - The replacement report is on account of additional information being submitted N - Not applicable as this is a new batch Z - Other reason Refer section 11.1.5.5 for further details on enumerations. PKI certificate number. PKICertificateNum This element is used when a digital certificate is used to authenticate the report.
Yes
10
No
11.1.5.1 Enumeration for MonthOfReport Code Description 01 02 03 04 05 06 07 08 09 10 11 12 NA January February March April May June July August September October November December Not Applicable (if there is no monthly reporting obligation e.g. STR)
11.1.5.2 Enumeration for YearOfReport Enumeration for YearOfReport is from 2005 to 2020. Value of NA (Not Applicable) may be used if there is no monthly reporting obligation e.g. STR.
45
Version 2.1
11.1.5.3 Enumeration for OperationalMode Code Description P T Production Mode Test Mode Remarks Live environment Test or training mode
11.1.5.4 Enumeration for BatchType Code Description N R D New Report Replacement Report Deletion Report Remarks Indicates a new report To be used when an earlier report has to be replaced with the current report To be used when an earlier report has to be deleted.
Acknowledgement of original batch Even if missing information has to be supplied a complete had many fatal, non fatal or replacement report has to be submitted instead of an probable errors which are being incremental report resolved Operational errors in original batch Both replacement and deletion report can be submitted if have been identified and reports are operational errors are detected being revised or deleted suo moto The replacement report is on Only replacement report can be submitted to provide additional account of additional information information being submitted Not applicable as this is a new batch All new or original batch will have this value Other reason If replacement or deletion reports is being submitted for reasons other than A, B or C above
C N Z
46
Version 2.1
11.1.6 element Batch/Report Report element provides details of the Reports in the batch. The Reports are uniquely identified by the ReportSerialNum. Figure: Overview of Reports
Table: Details of Batch/Reports Element Description The number uniquely represents a report within a batch. ReportSerialNum The ReportSerialNum should be unique within the batch. This number alongwith BatchID will uniquely identify any report received by FIU. The ReportSerialNum of the original report that has to be replaced or deleted. OriginalReportSerialNum This number alongwith OriginalBatchID will uniquely identify the report which is being replaced or deleted. In case there is no replacement or deletion of any report, mention 0 here. Name of the main person for the report. MainPersonName The reporting entity should try to identify one main person or legal entity in the report. Details of the Suspicion. This element will be present only in STR. Refer section 11.1.7 for details. Details of the Account. This element will not be present if account has not been opened. Refer section 11.1.8 for details. 80 Section 11.1.7 Section 11.1.8 No 8 Yes 8 Yes Length Mandatory
SuspicionDetails Account
No No
47
Version 2.1
11.1.7 element Batch/Report/SuspicionDetails SuspicionDetails provides information about the suspicion in the STR. This element is not required in other reports. Figure: Overview of Suspicion details
48
Version 2.1
Element
Table: Details of SuspicionDetails Description Source of alert for initiation of the STR. Permissible values are: CV Customer Verification WL - Watch List TY - Typology TM - Transaction Monitoring RM - Risk Management System MR - Media Reports LQ - Law Enforcement Agency Query EI - Employee Initiated PC - Public Complaint BA Business Associates ZZ - Others XX - Not Categorised Refer section 11.1.7.1 for further details on enumerations. Red Flag indicator which had generated alert resulting in STR. The reporting entity may use a standard language of the red flag indicator. The reporting entity may use the language used in the instructions of the regulator or communication of FIUIND. One STR can have more than one AlertIndicator. In the XML format more than one indicator can be mentioned for a report. In the fixed text format, the number of indicators for a report is limited to three. Whether the suspicion is on account of clause (a) of Rule 2(1) 2 (g) related to proceeds of an offence specified in the Schedule to the Act, regardless of the value involved.
Length Mandatory
SourceOfAlert
Yes
AlertIndicator
100
No
SuspicionDueToProceedsOfCrim Permissible values are: Y- Yes e N - No X Not categorised One STR may be related to more than one clause.
Yes
49
Version 2.1
Element
Description Whether the suspicion is on account of clause (b) of Rule 2(1) (g) related to circumstances of unusual or unjustified complexity.
Length Mandatory
SuspicionDueToComplexTrans
Permissible values are: Y- Yes N- No X Not categorised One STR may be related to more than one clause. Whether the suspicion is on account of clause (c) of Rule 2(1) (g) related to no economic rationale or bonafide purpose.
Yes
SuspicionDueToNoEcoRationale
Permissible values are: Y- Yes N - No X Not categorised One STR may be related to more than one clause. Whether the suspicion is on account of clause (d) of Rule 2(1) (g) related to financing of the activities related to terrorism.
Yes
SuspicionOfFinancingOfTerroris m
Permissible values are: Y- Yes N - No X Not categorised One STR may be related to more than one clause. Whether the STR relates to an attempted transaction that was not completed. Permissible values are: Y- Yes N - No X Not categorised
Yes
AttemptedTransaction
Yes
50
Version 2.1
Element
Description Summary of suspicion and sequence of events covering following aspects: Background/profile/occupation of the customer and other related individuals/entities. When did the relationship with the customer begin? How was suspicion detected? What information was linked or collected during the review process? What explanation was provided by the subject(s) or other persons (without tipping off)? Summary of suspicion Whether the suspicious activity is an isolated incident or relates to another transaction? Who benefited, financially or otherwise, from the transaction(s), how much, and how (if known)? What is the volume of transactions in reported accounts in the financial year, and what is the volume of cash transactions? Whether any STR filed for the customer earlier? Any additional information that might assist law enforcement authorities.
Length Mandatory
GroundsOfSuspicion
4000
Yes
Details about investigation being conducted covering the name of agency, contact person and contact details. DetailsOfInvestigation The investigation could be both internal to the reporting entity or any investigation by law enforcement agency. In case of law enforcement agency the details of contact person needs to be separately furnished under LEADetails below. Whether any Law enforcement agency is informed about the incident reported in the STR. Permissible values are: R - Information received S - Information sent N - No correspondence sent or received X - Not categorised. Refer section 11.1.7.2 for further details on enumerations. Contact details of person in the law enforcement agency which is conducting the investigation. LEADetails The details of the investigation should be furnished under DetailsOfInvestigation above. 250 No 4000 No
LEAInformed
Yes
51
Version 2.1
Element
Description Priority attached to the report as per assessment of the reporting entity. Permissible values are: P1 - Very High Priority P2 - High Priority P3 - Normal Priority XX - Not categorised The reporting entity can attach P1 priority for reports which requires immediate attention of FIU. Refer section 11.1.7.3 for further details on enumerations. Whether all the suspicious transactions are covered or a sample set is being reported? Permissible values are: C - Complete P - Partial X - Not categorised Refer section 11.1.7.4 for further details on enumerations. Whether the reporting entity wants to submit additional documents separately for the STR. Permissible values are: Y - Yes N - No X - Not categorised The reporting entity cant upload additional documents with the report. FIU-IND will send a separate request for providing additional information.
Length Mandatory
PriorityRating
Yes
ReportCoverage
Yes
AdditionalDocuments
Yes
11.1.7.1 Enumeration for SourceOfAlert Code Description CV Customer Verification Remarks Detected during customer acceptance, identification or verification (excluding reasons mentioned in other codes) (e.g. Use of forged ID, wrong address etc.) The customer details matched with watch lists (e.g. UN list, Interpol list etc.) Common typologies of money laundering, financing of terrorism or other crimes (e.g. structuring of cash deposits etc.) Transaction monitoring alert (e.g. unusually large transaction, increase in transaction volume etc.) Risk management system based alert (e.g. high risk customer, country, location, source of funds, transaction type etc.)
WL TY TM RM
52
Version 2.1
MR LQ
Adverse media reports about customer (e.g. newspaper reports) Query or letter received from law enforcement agency (LEA) or intelligence agency (e.g. blocking order received, transaction details sought etc.) Employee raised alert (e.g. behavioral indicators such as customer had no information about transaction, attempted transaction etc.) Complaint received from public (e.g. abuse of account for committing fraud etc.) Information received from other institutions, subsidiaries or business associates (e.g. cross-border referral, alert raised by agent etc.) Sources other than mentioned above The information is not available. No category has been selected
EI
Employee Initiated
PC
Public Complaint
BA ZZ XX
11.1.7.2 Enumeration for LEAInformed Code Description R S N X Information received Information sent No correspondence sent or received Not Categorised Remarks Correspondence has been received from any Law Enforcement Agency (LEA) on this case Matter has been referred to LEA for enquiries/investigations The LEA is not aware of the case The information is not available. No category has been selected
11.1.7.3 Enumeration for PriorityRating Code Description P1 P2 P3 XX Very High Priority High Priority Normal Priority Not Categorised Remarks For immediate attention by FIU For attention of FIU Reasonable time The information is not available. No category has been selected
53
Version 2.1
11.1.7.4 Enumeration for ReportCoverage Code Description C P X Complete Partial Not Categorised Remarks All suspicious transactions have been reported Reported transactions are sample transactions and there are many more similar transactions. The information is not available. No category has been selected
11.1.8 element Batch/Report/Account Account contains details of the account, branch, persons and transactions. Figure: Overview of Account
54
Version 2.1
Table: Details of Account Element AccountDetails Description Details of the account. Refer section 11.1.9 for details. Details of the branch associated with the account. Refer section 11.1.10 for details. Details of the person linked to the account. Refer section 11.1.14 for details. Details of the transaction in the account. Refer section 11.1.19 for details. Length Section 11.1.9 Mandatory Yes
Branch
Section 11.1.10
Yes
PersonDetails Transaction
Yes No
55
Version 2.1
11.1.9 element Batch/Report/Account/AccountDetails AccountDetails describes the account number, type, account status, turnover details and risk rating. Figure: Overview of Account Details
56
Version 2.1
Element AccountNumber
Table: Details of AccountDetails Description Account number Type of account. Permissible values are: BS - Savings Account BC - Current Account BR - Cash Credit/Overdraft Account BD - Credit Card Account BP - Prepaid Card Account BL - Loan Account BT - Term Deposit Account BG Letter of Credit/Bank Guarantee IL - Term Insurance Policy IE - Endowment Policy IA - Annuity Policy(Excluding ULIP) IU - ULIP Policy IH - Health Insurance Policy IM - Motor Insurance Policy IT - Travel Insurance Policy IB Money Back Policy IW Whole Life Policy ST - Trading Account MF Mutual Fund Folio DB - Beneficiary Client Account DH - Beneficiary House Account DC - Clearing Member Pool Account ZZ - Others XX - Not Categorised Refer section 11.1.9.1 for further details on enumerations.
Length 20
Mandatory Yes
AccountType
Yes
HolderName
80
Yes
57
Version 2.1
Element
Description Type of the account holder. Permissible values are: A - Resident Individual B - Legal Person/Entity (excluding C,D,E and F) C - Central/State Government D - Central/State Government owned undertaking E Reporting Entity F- Non Profit Organisation G- Non-residential individual H - Overseas corporate body/FII Z Others. X - Not categorised Refer section 11.1.9.2 for further details on enumerations. Status of the account. Permissible values are: A - Active I - Inactive D Dormant S - Suspended F - Frozen C - Closed Z - Others X - Not categorised Refer section 11.1.9.3 for further details on enumerations. Date of account opening.
Length
Mandatory
AccountHolderType
Yes
AccountStatus
Yes
DateOfOpening Mention the date in YYYY-MM-DD Format Risk category as per the internal risk assessment. Permissible values are: A1 - High Risk Account A2 - Medium Risk Account A3 - Low Risk Account XX - Not categorised Refer section 11.1.9.4 for further details on enumerations.
10
No
RiskRating
Yes
58
Version 2.1
Element
Description Sum of all credits in the Bank account from 1 April of the financial year till the last day of the month of reporting. If report is being furnished st for Jan 2010 then transactions from 1 April 2009 to 31st Jan 2010 have to be aggregated. The amount should be rounded off to nearest rupee without decimal. For STRs generated in the middle of the month, the transactions upto generation of alert needs to be aggregated. Sum of all debits in the account from 1 April of the financial year till the last day of the month/alert. The amount should be rounded off to nearest rupee without decimal. Sum of cash deposits in the account from 1 April of the financial year till the last day of the month/alert. The amount should be rounded off to nearest rupee without decimal.
st st st
Length
Mandatory
CumulativeCreditTurnover
20
No
CumulativeDebitTurnover
20
No
CumulativeCashDepositTurnover
20
No
Sum of cash withdrawals in the account from st CumulativeCashWithdrawalTurnov 1 April of the financial year till the last day of er the month/alert. The amount should be rounded off to nearest rupee without decimal. If no transaction is required to be reported. Permissible values are: Y Yes (No transaction to be reported) N - No (Transactions are reported) X Not Categorised NoTransactionsToBeReported* This information will be used to identify accounts in which no transactions are required to be reported due to threshold requirements (50,000/- for CTRs by banking companies) or attempted transactions (for STR). 11.1.9.1 Enumeration for AccountType Code Description BS BC BR BD BP BL BT Savings Account Current Account Cash Credit/Overdraft Account Credit Card Account Prepaid Card Account Loan Account Term Deposit Account Remarks Banks and other institutions Banks and other institutions Banks and other institutions Banks and other institutions Banks and other institutions Banks and other institutions Banks and other institutions
20
No
Yes
59
Version 2.1
Code Description BG IL IE IA IU IH IM IT IB IW ST MF DB DH DC ZZ XX Letter of Credit/Bank Guarantee Term Insurance Policy Endowment Policy Annuity Policy (Excluding ULIP) ULIP Policy Health Insurance Policy Motor Insurance Policy Travel Insurance Policy Money Back Policy Whole Life Policy Trading Account Mutual Fund Folio Beneficiary Client Account Beneficiary House Account Clearing Member Pool Account Others Not Categorised
Remarks Banks and other institutions Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies Stock Brokers Mutual Funds Depositories Depositories Depositories All Sectors The information is not available. No category has been selected
11.1.9.2 Enumeration for AccountHolderType Code Description A B C D E F G H Z X Resident Individual Legal Person/Entity Central/State Government Central/State Government undertaking Reporting Entity Non Profit Organisation Non- resident Individual Overseas corporate body/FII Others Not Categorised Not listed above The information is not available. No category has been selected The account belongs to other bank, financial institution or intermediary Excluding C,D,E, F Remarks
60
Version 2.1
11.1.9.3 Enumeration for AccountStatus Code A I D S F C Z X Description Active Inactive Dormant Suspended Frozen Closed Others Not Categorised Remarks Account is in regular use/policy inforce Account is not in regular use/ policy lapsed As defined by regulator (eg. There is no transaction in the account for two years)/ paid up policy lapsed after paying premiums for 3 or more years Account/policy risk is temporarily suspended Account/policy is frozen (including case of debit freeze) Account is closed/policy foreclosed, surrendered, death or maturity claim paid Not listed above The information is not available. No category has been selected
11.1.9.4 Enumeration for RiskRating Code Description A1 A2 A3 XX High Risk Account Medium Risk Account Low Risk Account Not Categorised The information is not available. No category has been selected Remarks Very High or High Risk
11.1.10 element Batch/Report/Account/Branch Branch provides information of the number and details of the branch associated with the account.
61
Version 2.1
Table: Details of Branch Element Description The type of branch reference number used. Permissible values are: R Regulator Issued B BIC I IFSC M MICR Code S Self generated Z Other sources X Not categorised Entities with no Branch reference number can be given a self generated number (S) to uniquely identify the branch. Refer section 11.1.10.1 for further details on enumerations. BranchRefNum BranchDetails The unique number to uniquely identify the branch. The type of BranchRefNum should be specified under BranchRefNumType above. Details of the branch associated with account. Refer section 11.1.11 for details. 20 Section 11.1.11 Yes No Length Mandatory
BranchRefNumType*
Yes
62
Version 2.1
11.1.10.1 Enumeration for BranchRefNumType Code R B I M S Z X Description Regulator Issued BIC IFSC MICR Code Self Generated Other sources Not Categorised Remarks Number issued or used by the regulator (other than B, I, M below) 11 digit Bank identifier code 11 digit Indian Financial System Code 9 digit Magnetic Ink Character Recognition Code The branch reference number mentioned in the report is a self generated unique number Sources other than mentioned above The information is not available. No category has been selected
11.1.11 element Batch/Report/Account/Branch/BranchDetails BranchDetails provides information of the branch associated to the account. Figure: Overview of BranchDetails
63
Version 2.1
Table: Details of BranchDetails Element BranchName BranchAddress BranchPhone BranchEmail Description Name of Branch Details of the branch address. Refer section 11.1.12 for details. Details of the branch phone. Refer section 11.1.13 for details. Branch email id Length 80 Section 11.1.12 Section 11.1.13 50 Mandatory Yes Yes Yes No
11.1.12 element Batch/Report/Account/Branch/BranchDetails/BranchAddress BranchAddress refers to the communication address of the branch. Refer section 11.1.4.1 for details of Type Address. 11.1.13 element Batch/Report/Account/Branch/BranchDetails/BranchPhone Refer section 11.1.4.2 for Type Phone. 11.1.14 element Batch/Report/Account/PersonDetails PersonDetails provides information on the person whether individual or a legal person.
64
Version 2.1
65
Version 2.1
Table: Details of PersonDetails Element PersonName CustomerID Description Full name of Individual or the Legal Person/Entity. Customer ID/Number. Relation of the person to the Account. Permissible values are: A - Account Holder B - Authorised Signatory C - Proprietor/Director/Partner/Member of a legal entity D - Introducer E Guarantor F - Guardian N Nominee O Beneficial Owner P Proposer G - Assignee L - Life Assured J Beneficiary H Power of Attorney Z - Others X - Not Categorised. Refer section 11.1.14.1 for further details on enumerations. CommunicationAddress Phone Email SecondAddress PAN UIN Details of the persons communication address. Refer section 11.1.15 for details. Details of the persons phones. Refer section 11.1.16 for details. Contact email. Details of the persons second or alternate address. Refer section 11.1.15 for details. Ten Digit PAN card number issued by Income Tax Department. Use UIDAI number for individuals and any other unique identification number for legal entity (if available). Choice compositor. Choice Whether person is Individual or Legal Person. Section 11.1.15 Section 11.1.16 50 Section 11.1.15 10 30 Section 11.1.17 & 11.1.18 Yes No No No No No Yes Length 80 10 Mandatory Yes No
RelationFlag
Yes
66
Version 2.1
11.1.14.1 Enumeration for RelationFlag Code Description A B C D E F N Account Holder Authorised Signatory Proprietor/Director/Partner/Member of a legal entity Introducer Guarantor Guardian Nominee Remarks Person in whose name the account stands Office or representative vested with the powers to commit the authorizing organisation to a binding agreement. Individuals linked to the legal entity in various capacities Person who introduced the account to the reporting entity A person who contracts to perform the promise, or discharge the liability, of a third person in case of his default. Person who operates the account on behalf of a minor E.g. Nominee as per section 45ZA of the BR act 1949, insurance Beneficial owner i.e the natural person who ultimately owns or controls a client and or the person on whose behalf a transaction is being conducted, and includes a person who exercises ultimate effective control over a juridical person Insurance Companies Insurance Companies Insurance Companies Insurance Companies Written document conferring authority on the agent to perform certain acts or functions on behalf of the principal. Banks, Insurance and Intermediaries Not listed above (including non customer in case of attempted transactions) The information is not available. No category has been selected
Beneficial Owner
P G L J
Power of Attorney
Z X
11.1.15 element Batch/Report/Account/PersonDetails/CommunicationAddress Refer section 11.1.4.1 for Type Address 11.1.16 element Batch/Report/Account/PersonDetails/Phone Refer section 11.1.4.2 for Type Phone
67
Version 2.1
11.1.17 element Batch/Report/Account/PersonDetails/Individual PersonDetails/Individual provides details of the individual and identification related information Figure: Overview of Individual
68
Version 2.1
Table: Details of Individual Element Description Sex of the Individual. Permissible values are: M- Male F- Female X- Not Categorised. Refer section 11.1.17.1 for further details on enumerations. DateOfBirth Date of Birth in YYYY-MM-DD format Document submitted as proof of identity of the individual. Permissible values are: A - Passport B - Election ID Card C - Pan Card D - ID Card E - Driving License F - Account Introducer G - UIDAI Letter H - NREGA job card Z Others Refer section 11.1.17.2 for further details on enumerations. IdentificationNumber IssuingAuthority PlaceOfIssue Nationality PlaceOfWork FatherOrSpouse Occupation Number mentioned in the identification document. Authority which had issued the identification document. Place where document was issued. Nationality of the person. Mention the two digit Country code as per ISO 3166 standards. Refer Annexure F for country codes Name of organisation/employer Full Name of Father/Spouse Job of the individual 2 80 80 50 Yes No No No 20 20 20 No No No 10 No Length Mandatory
Gender
Yes
IdentificationType
Yes
11.1.17.1 Enumeration for Gender Code Description M F X Male Female Not Categorised The information is not available. No category has been selected Remarks
11.1.17.2 Enumeration for IdentificationType Code Description A Passport Remarks Same as A used in version 1.0
69
Version 2.1
Code Description B C D E F G H Z Election Id Card Pan Card ID Card Driving License Account Introducer UIDAI letter NREGA job card Others
Remarks Same as B used in version 1.0 Same as C used in version 1.0 Same as D used in version 1.0 Same as E used in version 1.0 Same as F used in version 1.0 Issued by the Unique Identification Authority of India (UIDAI) Signed by an officer of the State Government Not listed above
11.1.18 element Batch/Report/Account/PersonDetails/LegalPerson LegalPerson provides information about Legal person or entity. Figure: Overview of Legal person
70
Version 2.1
Table: Details of LegalPerson Element Description Type of constitution of legal person/entity. Permissible values are: A - Sole Proprietorship B - Partnership Firm C - HUF D - Private Limited Company E - Public Limited Company F - Society G - Association H - Trust I - Liquidator J - LLP Z - Others X Not Categorised. Refer section 11.1.18.1 for further details on enumerations RegistrationNumber DateOfIncorporation PlaceOfRegistration CountryCode NatureOfBusiness Registration Number as mentioned in the document Date of incorporation in YYYY-MM-DD format Place where the document was registered. The two digit country code in which the entity is incorporated. Mention country code as per ISO 3166. Refer Annexure F for country codes. Nature of Business 20 10 20 2 50 No No No Yes No Length Mandatory
ConstitutionType
Yes
11.1.18.1 Enumeration for ConstitutionType Code Description A B C D E F G H I J Z X Sole Proprietorship Partnership Firm HUF Private Limited Company Public Limited Company Society Association Trust Liquidator LLP Others Not Categorised Limited Liability Partnership Not listed above The information is not available. No category has been selected Hindu Undivided family Remarks
71
Version 2.1
11.1.19 element Batch/Report/Account/Transaction Transaction provides information about the transactions in the account. Figure: Overview of Transaction
72
Version 2.1
Table: Details of Transaction Element DateOfTransaction TransactionID Description Date of transaction in YYYY-MM-DD format Unique ID to identify transaction (if available) Mode in which the transaction was conducted. Permissible values are: A Cheque B Internal Transfer C - Cash D - Demand Draft/Pay Order E - Electronic Fund Transfer F Exchange Based Transaction G Securities transaction S Switching Transaction Z Others X Not Categorised. Refer section 11.1.19.1 for details on enumerations. Debit or credit. Permissible values are: D - Debit C - Credit X - Not Categorised. Refer section 11.1.19.2 for details on enumerations. Amount of transaction. Amount The amount should be rounded off to nearest rupee without decimal. If this amount is not in Indian Rupees, then convert to Indian Rupees. Currency of transaction. Currency INR for Indian Rupees, Mention currency code as per ISO 4127. Refer Annexure G for Currency codes. Details of the products linked to the transaction. Refer section 11.1.20 for details. Reserved for later use. Use value X. Account number (if available) from/to which funds was transferred. Name of the institution (if available) from / to which funds were transferred. Institution reference number of the institution (if available) from / to which funds were transferred. RelatedInstitutionRefNum This reference number should enable linkage with the BranchRefNum in the element Batch/Report/Account/Branch which has been explained in section 11.1.10. Any additional information that needs to be provided. 20 No 3 Section 11.1.20 1 20 20 Yes 20 Yes Length 10 20 Mandatory Yes No
TransactionMode
Yes
DebitCredit
Yes
No No No No
Remarks
50
No
73
Version 2.1
11.1.19.1 Enumeration for TransactionMode Code Description A B C D E F G S Z X Cheque Internal Transfer Cash Demand Draft/Pay Order Electronic Fund Transfer Exchange Based Transaction Securities Transaction Switching Transaction Others Not Categorised Demand Draft, Pay Order Swift, cross border payment platforms, TT, RTGS, NEFT Any exchange based transaction Any Securities based transaction Switching transaction (switching of products) like switching of mutual funds Not listed above The information is not available Remarks Inter bank transfer Transfer within the Institution Code Used in Version 1.0 A B C D E New New New
11.1.19.2 Enumeration for DebitCredit Code Description D Debit Remarks Debit transaction in the account Banks - Withdrawal by customer Insurance companies - Payments made to customers, nominees Intermediaries Amount paid by the intermediary to the client Credit transaction in the account Banks - Deposit by customer Insurance companies Payments received from customers Intermediaries - Amount deposited by the client with intermediary Not Categorised
C X
Credit
74
Version 2.1
11.1.20 element Batch/Report/Account/Transaction/ProductTransaction ProductTransaction describes the various products if it is linked to the transaction. Figure: Overview of ProductTransaction
Table: Details of ProductTransaction Element Description Type of product linked with the transaction. Permissible values are: BD Bonds ST - Securities CD - Certificate of Deposit CP - Commercial Paper EQ - Equity Shares FU - Futures OP - Options DF - Debt Funds EF - Equity Fund HF - Hybrid Funds LF - Liquid Funds MF - MIP Funds XF - Exchange Traded Funds CO Commodities IP Insurance Products ZZ - Others XX - Not Categorised. Refer section 11.1.20.1 for details on enumerations. Product identitier Identifier Example- ISIN for security 30 No Length Mandatory
ProductType
Yes
75
Version 2.1
Element
Description Type of product transaction linked to the financial transaction Permissible values are: BP - Buy/Purchase SR - Sale/Redemption IA - Annuity payment IP - Pension IC - Commutation ID - Death claim IM - Maturity IB - Survival benefits IF - Free look cancellation IW - Withdrawal IS Surrender IG Assignment IE Decline IX Excess Refund IR Premium Payment IL Loan Repayment DD - Dematerialisation/Conversion of Mutual fund units in demat form DR Rematerialisation/Repurchase DO - Off Market trade DM - Market transfers DI - Inter Settlement transfers DP - Pledge and Hypothecation DC - Corporate action ZZ - Others XX - Not Categorised. Refer section 11.1.20.2 for further details on enumerations. Unit of product
Length
Mandatory
TransactionType
Yes
Units
If the product is measured in units, mention the number of units involved in the transaction. Unit rate of the product in Indian rupees
20
No
Rate
If the transaction involves a rate, update the applicable rate for the transaction.
10
No
11.1.20.1 Enumeration for ProductType Code BD ST CD CP Description Bonds Securities Certificate of Deposit Commercial Paper Remarks
76
Version 2.1
Code EQ FU OP DF EF HF LF MF XF CO IP ZZ XX
Description Equity Shares Futures Options Debt Funds Equity Fund Hybrid Funds Liquid Funds MIP Funds Exchange Traded Funds Commodities Insurance Products Others Not Categorised
Remarks
Mutual Funds Mutual Funds Mutual Funds Mutual Funds Mutual Funds Mutual Funds
Not listed above The information is not available. No category has been selected
11.1.20.2 Enumeration for TransactionType Code Description BP SR IA IP IC ID IM IB IF IW IS IG IE IX IR IL DD DR DO Buy/Purchase Sale/Redemption Annuity payment Pension Commutation Death claim Maturity Survival benefits Free look Cancellation Withdrawal Surrender Assignment Decline Excess Refund Premium Payment Loan Repayment Dematerialisation/Conversion of Mutual funds units in demat form Rematerialisation/Repurchase Off Market trade Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies (including money back) Insurance Companies Insurance Companies (including partial withdrawal) Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies Insurance Companies Depositories Depositories Depositories Remarks
77
Version 2.1
Code Description DM DI DP DC ZZ XX Market transfers Inter Settlement transfers Pledge and Hypothecation Corporate action Others Not Categorised
Remarks Depositories Depositories Depositories Depositories Not listed above The information is not available. No category has been selected
78
Version 2.1
11.2.1 Data structure of Batch File (ARFBAT.txt) S. No. Field Type Size From To Remarks Mapping to version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from 000001. This Line Number* number will be used during validation checks. Refer section 11.1.1 Report Name Refer section 11.1.2 Data Structure Version* Refer section 11.1.3 Complete name of Entity* Refer section 11.1.3 Category of Entity* Refer section 11.1.3 Regulator Issued code * Refer section 11.1.3 Unique ID issued by FIU* Refer section 11.1.4 Principal Officers Name* Refer section 11.1.4 Principal Officers Designation*
2 3 4 5 6 7 8 9
3 1 80 5 12 10 80 80
ReportingEntityCategory* CHAR RERegistrationNumber FIUREID* POName* PODesignation* CHAR CHAR CHAR CHAR
10
Address*
CHAR
225
278
502
Principal Officers Refer section 11.1.4 Address1* + Address2 + Address3 + Address 4 + Address5 Refer section 11.1.4 New field Refer section 11.1.4 New field
11 12
City StateCode*
CHAR CHAR
50 2
503 553
552 554
79
Version 2.1
S. No. Field 13 14 15 16 17 18 19 20 21 22 23 24 25 26 PinCode CountryCode* Telephone Mobile Fax POEmail* BatchNumber* BatchDate* MonthOfReport* YearOfReport* OperationalMode* BatchType* OriginalBatchId* ReasonOfRevision*
Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR NUM CHAR
Size 10 2 30 30 30 50 8 10 2 4 1 1 10 1
From 555 565 567 597 627 657 707 715 725 727 731 732 733 743
To 564 566 596 626 656 706 714 724 726 730 731 732 742 743
Refer section 11.1.4 New field Refer section 11.1.4 Principal Officers Telephone Refer section 11.1.4 New field Refer section 11.1.4 Principal Officers FAX Refer section 11.1.4 Principal Officers E-mail Refer section 11.1.5 Serial Number of Report* Refer section 11.1.5 Date of Report Refer section 11.1.5 Specified only in CTR Refer section 11.1.5 Specified only in CTR Refer section 11.1.5 Operational Mode* Refer section 11.1.5 Report Type* Refer section 11.1.5 Serial Number of Original Report *
11.2.2 Data structure of Report File (ARFRPT.txt) S. No. Field Type Size From To Remarks Mapping to version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from 000001. This Line Number* number will be used during validation checks. Refer section 11.1.6 New field Refer section 11.1.6 New field Refer section 11.1.6 New field Refer section 11.1.7 New field Refer section 11.1.7 New field Refer section 11.1.7 New field Refer section 11.1.7 New field Refer section 11.1.7 New field Refer section 11.1.7 New field Refer section 11.1.7 New field
2 3 4 5 6 7 8 9 10 11
80
Version 2.1
Type
Size
From
To
Remarks
SuspicionOfFinancingOf CHAR Terrorism* AttemptedTransaction* GroundsOfSuspicion* DetailsOfInvestigations LEAInformed* LEADetails PriorityRating* ReportCoverage* AdditionalDocuments* CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
408 409
Refer section 11.1.7 New field Refer section 11.1.7 New field Details of other investigations
4409 Refer section 11.1.7 Grounds of Suspicion* 8409 Refer section 11.1.7
8410 Refer section 11.1.7 New field 8660 Refer section 11.1.7 New field 8662 Refer section 11.1.7 New field 8663 Refer section 11.1.7 New field 8664 Refer section 11.1.7 New Field
11.2.3 Data structure of Branch File (ARFBRC.txt) S. No. Field Type Size From To Remarks Mapping to version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from Line Number* 000001. This number will be used during validation checks. Refer section 11.1.10 Refer section 11.1.10 Refer section 11.1.11 New field Branch Reference Number* Name of Branch* Branch Address1+ Address2+ Address3+ Address4+ Address5 New field New field Branch Pin code* New field Branch Telephone New field Branch Fax Branch E-mail
2 3 4
1 20 80
7 8 28
7 27 107
Address*
CHAR
225
108
332
6 7 8 9 10 11 12 13
50 2 10 2 30 30 30 50
Refer section 11.1.12 Refer section 11.1.12 Refer section 11.1.12 Refer section 11.1.12 Refer section 11.1.13 Refer section 11.1.13 Refer section 11.1.13 Refer section 11.1.11
81
Version 2.1
11.2.4 Data structure of Account File (ARFACC.txt) S. Field No. Type Size From To Remarks Mapping to version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from Line Number* 000001. This number will be used during validation checks. Refer section 11.1.6 New field Refer section 11.1.10 Branch Reference Number*
2 3 4 5 6 7 8 9 10 11 12 13 14 15
ReportSerialNum* BranchRefNum* AccountNumber* AccountType* HolderName* AccountHolderType* AccountStatus* DateOfOpening RiskRating* CumulativeCreditTurnover CumulativeDebitTurnover CumulativeCashDepositTurnover
NUM CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR NUM NUM NUM
8 20 20 2 80 1 1 10 2 20 20 20 20 1
14 34 54 56 136 137 138 148 150 170 190 210 230 231
Refer section 11.1.9 Account Number* Refer section 11.1.9 Type of Account Refer section 11.1.9 Refer section 11.1.9 Name of first/sole account holder Type of Account Holder* Date of Account opening* Cumulative Credit Turnover* Cumulative Debit Turnover* Cumulative Cash Deposit Turnover*
Refer section 11.1.9 Risk Category Refer section 11.1.9 Refer section 11.1.9 Refer section 11.1.9
Cumulative Cash Refer section 11.1.9 Withdrawal Turnover* Refer section 11.1.9 New field
82
Version 2.1
11.2.5 Data structure of Transaction File (ARFTRN.txt) S. No. Field Type Size From To Remarks Running sequence number for each line in the file starting from 000001. This number will be used during validation checks. Refer section 11.1.6 Refer section 11.1.10 Refer section 11.1.9 Refer section 11.1.19 Refer section 11.1.19 Refer section 11.1.19 Refer section 11.1.19 Refer section 11.1.19 Refer section 11.1.19 Refer section 11.1.20 Refer section 11.1.20 Refer section 11.1.20 Refer section 11.1.20 Refer section 11.1.20 Refer section 11.1.19 Refer section 11.1.19 Refer section 11.1.19 Refer section 11.1.19 Refer section 11.1.19 Mapping to version 1.0
Line Number*
NUM
Line Number*
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
ReportSerialNum* BranchRefNum* AccountNumber* DateOfTransaction* TransactionID TransactionMode* DebitCredit* Amount* Currency* ProductType* Identifier TransactionType Units Rate DispositionOfFunds RelatedAccountNum RelatedInstitutionName Remarks
NUM CHAR CHAR CHAR CHAR CHAR CHAR NUM CHAR CHAR CHAR CHAR NUM NUM CHAR CHAR CHAR CHAR
8 20 20 10 20 1 1 20 3 2 30 2 20 10 1 20 20 20 50
7 15 35 55 65 85 86 87 107 110 112 142 144 164 174 175 195 215 235
14 34 54 64 84 85 86 106 109 111 141 143 163 173 174 194 214 234 284
New field Branch Reference Number* Account Number* Date of Transaction* Transaction ID Mode of Transaction* Debit/Credit* Amount* Currency of Transaction* New field Security Identifier New field Number of security New field Disposition of Funds New field New field New field New field
RelatedInstitutionRefNum CHAR
83
Version 2.1
11.2.6 Data structure of Individual Data File (ARFINP.txt) S. No. Field Type Size From To Remarks Mapping to Version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from Line Number* 000001. This number will be used during validation checks. Refer section 11.1.6 Refer section 11.1.10 Refer section 11.1.9 Refer section 11.1.14 New field Branch Reference Number* Account Number* Full name of Individual*
2 3 4 5 6 7
ReportSerialNum* BranchRefNum* AccountNumber* PersonName* CustomerId RelationFlag* Communication Address* City StateCode* PinCode CountryCode* SecondAddress City StateCode* PinCode CountryCode* Telephone Mobile Fax Email PAN
8 20 20 80 10 1
7 15 35 55 135 145
Refer section 11.1.14 Customer ID/Number Refer section 11.1.14 Relation Flag* Communication Address 1* + Refer section 11.1.15 Address2 + Address3 + Address4 + Address5 Refer section 11.1.15 New field Refer section 11.1.15 New field Refer section 11.1.15 Communication Address Pin code*
CHAR
225
146
370
9 10 11 12 13 14 15 16 17 18 19 20 21 22
CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
50 2 10 2 225 50 2 10 2 30 30 30 50 10
371 421 423 433 435 660 710 712 722 724 754 784 814 864
420 422 432 434 659 709 711 721 723 753 783 813 863 873
Refer section 11.1.15 New field Second Address1 + Address2 + Address3 Refer section 11.1.15 + Address4 + Address5 Refer section 11.1.15 New field Refer section 11.1.15 New field Refer section 11.1.15 Second Address Pin code*
Refer section 11.1.15 New field Refer section 11.1.16 Contact Telephone Refer section 11.1.16 Contact Mobile number
Refer section 11.1.16 New field Refer section 11.1.14 Contact E-mail Refer section 11.1.14 PAN
84
Version 2.1
S. No. Field 23 24 25 26 27 28 29 30 31 32 33 UIN Gender* DateOfBirth IdentificationType* IdentificationNumber IssuingAuthority PlaceOfIssue Nationality* PlaceOfWork FatherOrSpouse Occupation
Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
Size 30 1 10 1 20 20 20 2 80 80 50
From 874 904 905 915 916 936 956 976 978 1058 1138
To 903 904 914 915 935 955 975 977 1057 1137 1187
Remarks
Refer section 11.1.14 New field Refer section 11.1.17 Sex Refer section 11.1.17 Date of Birth Refer section 11.1.17 Type of Identification Refer section 11.1.17 Identification Number Refer section 11.1.17 Issuing Authority Refer section 11.1.17 Place of Issue Refer section 11.1.17 Nationality Refer section 11.1.17 Place of Work Refer section 11.1.17 Name of Father/Spouse
11.2.7 Data structure of Legal Person/Entity Data File (ARFLPE.txt) S. No. Field Type Size From To Remarks Mapping to Version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from Line Number* 000001. This number will be used during validation checks. Refer section 11.1.6 Refer section 11.1.10 Refer section 11.1.9 Refer section 11.1.14 New field Branch Reference Number* Account Number* Name of Legal Person /Entity*
2 3 4 5 6 7
ReportSerialNum* BranchRefNum* AccountNumber* PersonName* CustomerId RelationFlag* Communication Address* City StateCode* PinCode CountryCode*
8 20 20 80 10 1
7 15 35 55 135 145
Refer section 11.1.14 Customer ID/Number Refer section 11.1.14 Relation Flag* Communication Address 1* + Refer section 11.1.15 Address2 + Address3 + Address4 + Address5 Refer section 11.1.15 New field Refer section 11.1.15 New field Refer section 11.1.15 Communication Address Pin code*
CHAR
225
146
370
9 10 11 12
50 2 10 2
85
Version 2.1
S. No. Field
Type
Size
From
To
Remarks
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Second Address City StateCode* PinCode CountryCode* Telephone Mobile Fax Email PAN UIN ConstitutionType* RegistrationNumber DateOfIncorporation PlaceOfRegistration CountryCode* NatureOfBusiness
CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
225 50 2 10 2 30 30 30 50 10 30 1 20 10 20 2 50
435 660 710 712 722 724 754 784 814 864 874 904 905 925 935 955 957
659 709 711 721 723 753 783 813 863 873 903 904 924 934 954 956 1006
Second Address1 + Address2 + Address3 Refer section 11.1.15 + Address4 + Address5 Refer section 11.1.15 New field Refer section 11.1.15 New field Refer section 11.1.15 Communication Address Pin code*
Refer section 11.1.15 New field Refer section 11.1.16 Contact Telephone Refer section 11.1.16 Contact Mobile number
Refer section 11.1.16 New field Refer section 11.1.14 Contact E-mail Refer section 11.1.14 PAN Refer section 11.1.14 New field Refer section 11.1.18 Type of Constitution* Refer section 11.1.18 Registration Number Refer section 11.1.18 Date of Incorporation Refer section 11.1.18 Place of Registration Refer section 11.1.18 New field Refer section 11.1.18 Nature of Business
86
Version 2.1
S. No. 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
Element Batch / PrincipalOfficer / POAddress / CountryCode Batch / BatchDetails / MonthOfReport Batch / BatchDetails / YearOfReport Batch / BatchDetails / OperationalMode Batch / BatchDetails / BatchType Batch / BatchDetails / ReasonOfRevision Batch / Report / SuspicionDetails / SourceOfAlert Batch / Report / SuspicionDetails / SuspicionDueToProceedsOfCrime Batch / Report / SuspicionDetails / SuspicionDueToComplexTrans Batch / Report / SuspicionDetails / SuspicionDueToNoEcoRationale Batch / Report / SuspicionDetails / SuspicionOfFinancingOfTerrorism Batch / Report / SuspicionDetails / AttemptedTransaction Batch / Report / SuspicionDetails / LEAInformed Batch / Report / SuspicionDetails / PriorityRating Batch / Report / SuspicionDetails / ReportCoverage Batch / Report / SuspicionDetails / AdditionalDocuments Batch / Report / Account / AccountDetails / AccountType Batch / Report / Account / AccountDetails / AccountHolderType Batch / Report / Account / AccountDetails / AccountStatus Batch / Report / Account / AccountDetails / RiskRating Batch / Report / Account / AccountDetails / NoTransactionsTobeReported Batch / Report / Account / Branch / BranchRefNumType
Section Annexure F Section 11.1.5.1 Section 11.1.5.2 Section 11.1.5.3 Section 11.1.5.4 Section 11.1.5.5 Section 11.1.7.1 Section 11.1.7 Section 11.1.7 Section 11.1.7 Section 11.1.7 Section 11.1.7 Section 11.1.7.2 Section 11.1.7.3 Section 11.1.7.4 Section 11.1.7 Section 11.1.9.1 Section 11.1.9.2 Section 11.1.9.3 Section 11.1.9.4 Section 11.1.9 Section 11.1.10.1
Batch / Report / Account / Branch / BranchDetails / BranchAddress / StateCode Annexure E Batch / Report / Account / Branch / BranchDetails / BranchAddress / CountryCode Batch / Report / Account / PersonDetails / RelationFlag Batch / Report / Account / PersonDetails / CommunicationAddress / StateCode Batch / Report / Account / PersonDetails / CommunicationAddress / CountryCode Batch / Report / Account / PersonDetails / SecondAddress / StateCode Batch / Report / Account / PersonDetails / SecondAddress / CountryCode Batch / Report / Account / PersonDetails / Individual / Gender Annexure F Section 11.1.14.1 Annexure E Annexure F Annexure E Annexure F Section 11.1.17.1
87
Version 2.1
S. No. 36 37 38 39 40 41 42 43 44
Element Batch / Report / Account / PersonDetails / Individual / IdentificationType Batch / Report / Account / PersonDetails / Individual / Nationality Batch / Report / Account / PersonDetails / LegalPerson / ConstitutionType Batch / Report / Account / PersonDetails / LegalPerson / CountryCode Batch / Report / Account / Transaction / TransactionMode Batch / Report / Account / Transaction / DebitCredit Batch / Report / Account / Transaction / Currency Batch / Report / Account / Transaction / ProductTransaction / ProductType Batch / Report / Account / Transaction / ProductTransaction / TransactionType
Section Section 11.1.17.2 Annexure F Section 11.1.18.1 Annexure F Section 11.1.19.1 Section 11.1.19.2 Annexure F Section 11.1.20.1 Section 11.1.20.2
11.3.2 Mandatory Validation Rule Matrix In addition to the enumerations, the validations for mandatory elements will be conducted by schema level validation and rule based validation. The mandatory value is being specified at following levels: MandatoryValue in XSD Rule based (Fatal) (Specifed as MandatoryValueFatal) Rule based (Non Fatal) (Specifed as MandatoryValueNonFatal)
The rules for validation will be specified in the external rule file (SCH format) which could be revised from time to time. The sample matrix of the mandatory validation is as under: S. Element No. 1 2 3 4 5 6 7 8 9 Batch / ReportingEntity / ReportingEntityName Batch / ReportingEntity / RERegistrationNumber Batch / ReportingEntity / FIUREID Batch / PrincipalOfficer / POName Batch / PrincipalOfficer / PODesignation Batch / PrincipalOfficer / POAddress / Address Batch / PrincipalOfficer / POAddress / PinCode Batch / PrincipalOfficer / POPhone / Telephone Batch / PrincipalOfficer / POPhone / Mobile Y Y Y Y Y Y Y Y Y Y Y Mandatory Value in XSD Y Y Rule based (Fatal) Rule based (Non Fatal)
10 Batch / PrincipalOfficer / POPhone / Fax 11 Batch / PrincipalOfficer / POEmail 12 Batch / BatchDetails / BatchNumber 13 Batch / BatchDetails / BatchDate
88
Version 2.1
S. Element No. 14 Batch / BatchDetails / OriginalBatchID 15 Batch / Report / ReportSerialNum 16 Batch / Report / OriginalReportSerialNum 17 Batch / Report / MainPersonName 18 Batch / Report / SuspicionDetails / GroundsOfSuspicion 19 Batch / Report / SuspicionDetails / DetailsOfInvestigations 20 Batch / Report / Account / AccountDetails / AccountNumber 21 Batch / Report / Account / AccountDetails / HolderName 22 Batch / Report / Account / AccountDetails / DateOfOpening 23 24 25 26 Batch / Report / Account / AccountDetails / CumulativeCreditTurnover Batch / Report / Account / AccountDetails / CumulativeDebitTurnover Batch / Report / Account / AccountDetails / CumulativeCashDepositTurnover Batch / Report / Account / AccountDetails / CumulativeCashWithdrawlTurnover
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
27 Batch / Report / Account / Branch / BranchRefNum 28 29 30 Batch / Report / Account / Branch / BranchDetails / BranchAddress / Address Batch / Report / Account / Branch / BranchDetails / BranchAddress / City Batch / Report / Account / Branch / BranchDetails / BranchAddress / PinCode
31 Batch / Report / Account / PersonDetails / PersonName 32 33 34 Batch / Report / Account / PersonDetails / CommunicationAddress / Address Batch / Report / Account / PersonDetails / CommunicationAddress / City Batch / Report / Account / PersonDetails / CommunicationAddress / PinCode
35 Batch / Report / Account / PersonDetails / PAN 36 37 38 Batch / Report / Account / PersonDetails / Individual / DateOfBirth Batch / Report / Account / PersonDetails / Individual / IdentificationNumber Batch / Report / Account / PersonDetails / Individual / FatherOrSpouse
89
Version 2.1
40 Batch / Report / Account / Transaction / DateOfTransaction 41 Batch / Report / Account / Transaction / Amount 11.3.3 Other rules for Preliminary Rule Validation (PRV)
Y Y
In addition to the enumeration and mandatory validations, rules will also be specified in the external rule file (SCH format) which could be revised from time to time. Explanation of sample rules is as under: S. No. 1 2 3 4 5 6 7 Element Batch / PrincipalOfficer / POAddress / Address Batch / PrincipalOfficer / POPhone / Telephone Batch / PrincipalOfficer / POPhone / Mobile Batch / PrincipalOfficer / POEmail Batch / BatchDetails / BatchDate Batch / BatchDetails / BatchDate Batch / BatchDetails / MonthOfReport Batch / BatchDetails / YearOfReport Batch / Report / ReportSerialNum Batch / Report / SuspicionDetails / SourceOfAlert Batch / Report / Account / AccountDetails / AccountNumber Validation Rule Type SufficiencyLengthNonFatal SufficiencyLengthNonFatal SufficiencyLengthNonFatal SufficiencyLengthNonFatal ConsistencyValue ErrorProbablityHigh ErrorProbablityHigh Explanation Length should be minimum 8 Length should be minimum 6 Length should be minimum 6 Length should be minimum 6 Value should be earlier than system date Value is less than one year from system date Value is NA for CTR Value is NA for CTR
ErrorProbablityHigh
UniqueValue
Value should be unique in a batch If ReportType is STR, at least one "SuspicionDetail" element should be present for each report Account number with Branch reference number should be unique in a report
10
SufficiencyElementFatal
11
UniqueValue
90
Version 2.1
S. No. 12
Element Batch / Report / Account / AccountDetails / NoTransactionsTobeReported Batch / Report / Account / PersonDetails / RelationFlag Batch / Report / Account / PersonDetails / RelationFlag Batch / Report / Account / PersonDetails / Individual / IdentificationNumber Batch / Report / Account / Branch / BranchDetails / BranchAddress / Address Batch / Report / Account / PersonDetails / CommunicationAddress / Address Batch / Report / Account / AccountDetails / DateOfOpening Batch / Report / Account / AccountDetails / CumulativeCreditTurnover Batch / Report / Account / AccountDetails / CumulativeDebitTurnover Batch / Report / Account / AccountDetails / CumulativeCashDepositTurnov er Batch / Report / Account / AccountDetails / CumulativeCashDepositTurnov er Batch / Report / Account / AccountDetails / CumulativeCashWithdrawalTur nover
Explanation If the value is 'N, at least one Transaction record should be present Value of at least one element in the account should be "A".(Account Holder) For every legal person with this flag as "A", there should be at least one individual person record Length should be minimum 5
13
SufficiencyElementFatal
14
SufficiencyElementNonFatal
15
SufficiencyLengthNon Fatal
16
SufficiencyLengthNonFatal
17
SufficiencyLengthNonFatal
18
ConsistencyValue
Value should be earlier than system date Value should be greater than or equal to credit transaction amount Value should be greater than or equal to debit transaction amount The value should not be less than transaction amount with "DebitCredit" as "C" and TransactionMode as "C".
19
ConsistencyValue
20
ConsistencyValue
21
ConsistencyValue
22
ConsistencyValue
23
ConsistencyValue
The value should not be less than transaction amount with "DebitCredit" as "D" and TransactionMode as "C".
91
Version 2.1
S. No.
Element Batch / Report / Account / AccountDetails / CumulativeCashWithdrawlTurn over Batch / Report / Account / PersonDetails / Individual / DateOfBirth Batch / Report / Account / PersonDetails / LegalPerson / DateOfIncorporation Batch / Report / Account / Transaction / DateOfTransaction Batch / Report / Account / Transaction / Amount Batch / Report / Account / Transaction / Amount Batch / Report / Account / Transaction / DateOfTransaction Batch / Report / Account / Transaction / Amount Batch / Report / Account / Transaction / Amount Batch / Report / Account / Transaction / Amount
Explanation
24
ConsistencyValue
25
ConsistencyValue
Value should not be greater than system date Value should not be greater than system date Value should not be greater than system date Sum of Credit transactions should not be greater than the Cumulative Credit Turnover Sum of Debit transactions should not be greater than the Cumulative Debit Turnover Value should not be earlier than one year from system date Transaction amount is equal to the account number. Value of a single cash transaction exceeds 1billion INR. Multiple transactions of the same value on the same day.
26
ConsistencyValue
27
ConsistencyValue
28
ConsistencyValue
29
ConsistencyValue
30
ErrorProbablityHigh
31 32 33
92
Version 2.1
11.3.4 Sample Rules for Advanced Rule Validation (ARV) The rules for Advanced Rule Validation (ARV) will be specified in the internal system of FIU. Explanation of sample rules is as under: S. No. 1 Element Batch / Report / Account / Branch / BranchDetails / BranchAddress / Address Batch / Report / Account / PersonDetails / CommunicationAddress / Address Batch / Report / Account / AccountDetails / CumulativeCreditTurnover Validation Rule Type SufficiencyValue Explanation The address should contain sufficient information (dictionary based) The address should contain sufficient information (dictionary based) The cumulative credit amount in the year should not be lower than the report of the previous month, with an exception for April. The cumulative debit amount in the year should not be lower than the report of the previous month, with an exception for April. The pincode of the branch should match with the pincode dictionary The pincode of the customer should match with the pincode dictionary The PAN of the customer should be a valid PAN in Income Tax Database
SufficiencyValue
ConsistencyValueEarlierReport
Batch / Report / Account / AccountDetails / CumulativeDebitTurnover Batch / Report / Account / Branch / BranchDetails / BranchAddress / PinCode Batch / Report / Account / PersonDetails / CommunicationAddress / PinCode Batch / Report / Account / PersonDetails / PAN
ConsistencyValueEarlierReport
ConsistencyValueInternalSource
ConsistencyValueInternalSource
ConsistencyValueExternalSource
93
Version 2.1
94
Version 2.1
12.1.6 element Batch/Report Report element provides details of the Reports in the batch. The Reports are uniquely identified by the ReportSerialNum.
Table: Details of Report Element Description The number uniquely represents a report within a batch. ReportSerialNum The ReportSerialNum should be unique within a batch. This number alongwith BatchId will uniquely identity any report received by FIU The ReportSerialNum of the original report that has to be replaced or deleted. This number alongwith OriginalBatchID will 8 Yes Length Mandatory
OriginalReportSerialNum
Yes
95
Version 2.1
Element
Description uniquely identify the report which is being replaced or deleted. In case there is no replacement or deletion of any original report, mention 0 here. Name of the main person for the report.
Length
Mandatory
MainPersonName
The reporting entity should try to identify one main person or legal entity in the report. This will assist in future reference. Details of the suspicion. Refer section 12.1.7 for details. Details of the transaction. Refer section 12.1.8 for details. Details of the institutions related to the transaction. Refer section 12.1.12 for details. Details of the payment instrument related to the transaction. Refer section 12.1.15 for details. Details of the persons related to the transaction. Refer section 12.1.16 for details.
80
No
Section 12.1.7 Section 12.1.8 Section 12.1.12 Section 12.1.15 Section 12.1.16
No No Yes No No
12.1.7 element Batch/Report/SuspicionDetails SuspicionDetails provides information about the suspicion in the STR. Figure: Overview of SuspicionDetails
96
Version 2.1
Element
Table: Details of SuspicionDetails Description Source of alert for initiation of the STR. Permissible values are: CV Customer Verification WL - Watch List TY- Typology TM - Transaction Monitoring RM - Risk Management System MR - Media Reports LQ - Law Enforcement Agency Query EI - Employee Initiated PC Public Complaint BA Business Associates ZZ - Others XX - Not Categorised Refer section 12.1.7.1 for further details on enumerations. Red Flag indicator which had generated alert resulting in STR. The reporting entity may use a standard language of the red flag indicator. The reporting entity may use the language used in the instructions of the regulator or communication of FIUIND. One STR can have more than one AlertIndicator. In the XML format more than one indicator can be mentioned for a report. In the fixed text format, the number of indicators for a report is limited to three. Whether the suspicion is on account of clause (a) of Rule 2(1)(g) related to proceeds of an offence specified in the Schedule to the Act, regardless of the value involved.
Length Mandatory
SourceOfAlert
Yes
AlertIndicator
100
No
SuspicionDueToProceedsOfCr Permissible values are: ime Y- Yes N - No X Not categorised One STR may be related to more than one clause. Whether the suspicion is on account of clause (b) of Rule 2(1) (g) related to circumstances of unusual or unjustified complexity. SuspicionDueToComplexTran Permissible values are: s Y- Yes N- No X Not categorised One STR may be related to more than one clause.
Yes
Yes
97
Version 2.1
Element
Description Whether the suspicion is on account of clause (c) of Rule 2(1) (g) related to no economic rationale or bonafide purpose.
Length Mandatory
SuspicionDueToNoEcoRation ale
Permissible values are: Y- Yes N - No X Not categorised One STR may be related to more than one clause. Whether the suspicion is on account of clause (d) of Rule 2(1) (g) related to financing of the activities related to terrorism.
Yes
SuspicionOfFinancingOfTerror ism
Permissible values are: Y- Yes N - No X Not categorised One STR may be related to more than one clause. Whether the STR relates to an attempted transaction that was not completed.
Yes
AttemptedTransaction
Permissible values are: Y- Yes N - No X Not categorised Summary of suspicion and sequence of events covering following aspects: Background/profile/occupation of the customer and other related individuals/entities. When did the relationship with the customer begin? How was suspicion detected? What information was linked or collected during the review process? What explanation was provided by the subject(s) or other persons (without tipping off)? Summary of suspicion Whether the suspicious activity is an isolated incident or relates to another transaction? Who benefited, financially or otherwise, from the transaction(s), how much, and how (if known)? Whether any STR filed for the customer earlier? Any additional information that might assist law enforcement authorities.
Yes
GroundsOfSuspicion
4000
Yes
98
Version 2.1
Element
Description Details about investigation being conducted covering the name of agency, contact person and contact details.
Length Mandatory
DetailsOfInvestigation
The investigation could be both internal to the reporting entity or any investigation by law enforcement agency. In case of law enforcement agency the details of contact person needs to be separately furnished under LEADetails below. Whether any Law enforcement agency is informed about the incident reported in the STR. Permissible values are: R - Information received S - Information sent N - No correspondence sent or received X - Not categorised. Refer section 12.1.7.2 for further details on enumerations. Contact details of person in the law enforcement agency which is conducting the investigation.
4000
No
LEAInformed
Yes
LEADetails The details of the investigation should be furnished under DetailsOfInvestigation above. Priority attached to the report as per assessment of the reporting entity. Permissible values are: P1 - Very High Priority P2 - High Priority P3 - Normal Priority XX - Not categorised The reporting entity can attach P1 priority for reports which requires immediate attention of FIU. Refer section 12.1.7.3 for further details on enumerations. Whether all the suspicious transactions are covered or a sample set is being reported? ReportCoverage Permissible values are: C - Complete P - Partial X - Not categorised Refer section 12.1.7.4 for further details on enumerations.
250
No
PriorityRating
Yes
Yes
99
Version 2.1
Element
Description Whether the reporting entity wants to submit additional documents separately for the STR. Permissible values are: Y - Yes N - No X - Not categorised The reporting entity cant upload additional documents with the report. They will be sent a separate request for providing additional information.
Length Mandatory
AdditionalDocuments
Yes
Remarks Detected during customer acceptance, identification or verification (excluding reasons mentioned in other codes) The customer details matched with a watch list (UN list, Interpol list etc.) Common typologies of money laundering, financing of terrorism or other crimes (e.g. structuring of cash deposits etc.) Transaction monitoring alert (e.g. unusually large transaction, increase in transaction volume etc.) Risk management system based alert (high risk customer, country, location, source of funds, transaction type etc.) Adverse media reports about customer (Newspaper reports) Query or letter received from law enforcement agency (LEA) or intelligence agency (e.g. blocking order received, transaction details sought etc.) Employee raised alert (e.g. behavioral indicators such as customer had no information about transaction, attempted transaction etc.) Complaint received from public (e.g. abuse of account for committing fraud etc.) Information received from other institutions, subsidiaries or business associates (e.g. cross-border referral, alert raised by agent etc.) Sources other than mentioned above The information is not available. No category has been selected
TM RM MR LQ
Transaction Monitoring Risk Management System Media Reports Law Enforcement Agency Query
EI
Employee Initiated
PC
Public Complaint
BA ZZ XX
100
Version 2.1
12.1.7.2 Enumeration for LEAInformed Code Description R S N X Information received Information sent No correspondence sent or received Not Categorised Remarks Correspondence has been received from any Law Enforcement Agency (LEA) on this case Matter has been referred to LEA for enquiries/investigations The LEA is not aware of the case The information is not available. No category has been selected
12.1.7.3 Enumeration for PriorityRating Code Description P1 P2 P3 XX Very High Priority High Priority Normal Priority Not Categorised Remarks For immediate attention by FIU For attention of FIU Reasonable time The information is not available. No category has been selected
12.1.7.4 Enumeration for ReportCoverage Code Description C P X Complete Partial Not Categorised Remarks All suspicious transactions have been reported Reported transactions are sample transactions and there are many more similar transactions. The information is not available. No category has been selected
101
Version 2.1
12.1.8 element Batch/Report/Transaction Transaction provides information about the transaction, payment instrument, persons and institutions related with the transaction. Figure: Overview of Transaction
102
Version 2.1
Table: Details of Transaction Element TransactionDate TransactionTime Description Date of transaction in YYYY-MM-DD Format Time of transaction in HH:MM:SS Format Unique Reference Number for transactions maintained by the reporting entity. TransactionRefNum In cases, where the reporting entity is reporting two (or more) transactions intrinsically linked to each other (money transfer sent and received), both the records should have common Transaction Reference Number to depict the complete transaction. Type of transaction conducted. Permissible values are: P- Purchase R- Redemption Refer section 12.1.8.1 for further details on enumerations. Type of instrument used. Permissible Values are: A - Currency Note B - Travelers Cheque C - Demand Draft/Pay Order D - Money Order E - Wire Transfers/TT F - Money Transfer G - Credit Card H - Debit Card I - Smart Card J - Prepaid Card K - Gift Card L- Cheque Z - Others X - Not categorised. Refer section 12.1.8.2 for further details on enumerations. Name of the institution where transaction was conducted. TransactionInstitutionName* In case of money transfer or money exchange, the record should contain name of the entity (agent) where transaction was conducted. In case of card system operators, this refers to the merchant where transaction was conducted. 80 Yes 20 No Length 10 8 Mandatory Yes No
TransactionType
Yes
InstrumentType
Yes
103
Version 2.1
Element
Description Unique reference number to uniquely identify the branch/office of the institution where the transaction was conducted.
Length
Mandatory
TransactionInstitutionRefNum
The number may be issued by the regulator/BIC MICR/IFSC/self generated or other sources. Refer to earlier enumeration BranchRefNumType in section 11.1.10.1 for further details. State code that identifies the state of the institution where transaction was conducted.
20
Yes
TransactionStateCode
In case of India mention the two digit state code as per Indian Motor Vehicle Act 1988. Refer Annexure E for State codes Two digit country code for the country where transaction was conducted as per ISO 3166.
Yes
TransactionCountryCode
Use IN for India. Refer to Annexure F for Country codes. Unique number of the payment instrument/card.
Yes
PaymentInstrumentNum
20 80
No No
PaymentInstrumentIssueInstitutionName Name of the institution that has issued the payment instrument/card Unique reference number of the institution that has issued the payment instrument/card. InstrumentIssueInstitutionRefNum The number may be issued by the regulator/BIC MICR/IFSC/self generated or other sources. Refer to earlier enumeration BranchRefNumType in section 11.1.10.1 for further details. Two digit country code for the Country where transaction was conducted as per ISO 3166. InstrumentCountryCode Use IN for India. Refer to Annexure F for Country codes. Amount of transaction in rupees. AmountRupees The amount should be rounded off to nearest rupee without decimal. If this amount was not in Indian Rupees, it should be converted into Indian Rupees. Amount of transaction in foreign currency (if applicable). AmountForeignCurrency The amount should be rounded off without decimal
20
No
No
20
Yes
20
No
104
Version 2.1
Element
Length
Mandatory
CurrencyOfTransaction
Mention three digit Currency Codes as per ISO 4127. Refer Annexure G for Currency codes. Purpose of transaction
No
PurposeOfTransaction
Define the purpose (such as Private Visit, Visa fees) Purpose code prescribed by RBI in RRETURN6.txt for loading data into the FETERS. Refer RBI FETERS Purpose codes. Risk Rating of the transaction as per the internal risk assessment of the reporting entity. Permissible values are: T1 - High Risk Transaction T2 - Medium Risk Transaction T3 - Low Risk Transaction XX - Not categorised. Refer section 12.1.8.3 for further details on enumerations. Details of the customer linked to the transaction. Refer section 12.1.9 for details.
100
Yes
PurposeCode
Yes
RiskRating
Yes
Customer Details
Section 12.1.9
Yes
AccountNumber AccountWithInstitutionName
Bank account number if it is linked to the transaction (if available). Name of the financial institution having the account linked to the transaction (if available). Unique reference number of the institution having the account linked to the transaction. This reference number would enable linkage with the details of the institution in TRFBRC.txt
20 80
No No
AccountWithInstitutionRefNum
The number may be issued by the regulator/ BIC/ MICR/IFSC/self generated or other sources. Refer to earlier enumeration BranchRefNumType in section 11.1.10.1 for further details. Name of the financial institution related to the transaction (if available).
20
No
RelatedInstitutionName
80
No
105
Version 2.1
Element
Description Role of the institution in the transaction. Permissible values are: D - Acquirer Institution E - Senders Correspondent Institution F - Receivers Correspondent Institution Z - Others X - Not categorised. Refer section 12.1.8.4 for further details on enumerations. Unique reference number of the institution related to the transaction. This reference number would enable linkage with the details of the institution in TRFBRC.txt
Length
Mandatory
InstitutionRelationFlag
No
RelatedInstitutionRefNum
The number may be issued by the regulator/BIC/MICR/IFSC/self generated or other sources. Refer to earlier enumeration BranchRefNumType in section 11.1.10.1 for further details. Other information related to the transaction.
20
No
Remarks
50
No
12.1.8.1 Enumeration for TransactionType Code Description P Purchase Remarks Authorised money exchanger - Purchase of forex/TC by customer Money transfer service - Sending money transfer Card operator Purchase of card or payment towards card. Authorised money exchanger - Sale of forex/TC by customer Money transfer service Receipt of money transfer Card operator Use of card for purchases
Redemption
12.1.8.2 Enumeration for InstrumentType Code Description A B C D E F Currency Note Travelers Cheque Demand Draft/Pay order Money Order Wire Transfers/TT Money Transfer Remarks
106
Version 2.1
Code Description G H I J K L Z X Credit Card Debit Card Smart Card Prepaid Card Gift Card Cheque Others Not Categorised
Remarks
Not listed above The information is not available. No category has been selected
12.1.8.3 Enumeration for RiskRating Code Description T1 T2 T3 XX High Risk Transaction Medium Risk Transaction Low Risk Transaction Not Categorised The information is not available. No category has been selected Remarks Very High or High Risk
12.1.8.4 Enumeration for InstitutionRelationFlag Code Description D E F Z X Acquirer Institution Senders Correspondent Institution Receivers Correspondent Institution Others Not categorised Remarks Used in case of card transactions Used in case of SWIFT transactions Used in case of SWIFT transactions Not listed above The information is not available. No category has been selected
107
Version 2.1
12.1.9 element Batch/Report/Transaction/CustomerDetails CustomerDetails provides information on the identity of the customer related to the transaction. Figure: Overview of CustomerDetails
Table: Details of CustomerDetails Element CustomerName CustomerId Occupation DateOfBirth Description Full Name of the customer/sender/receiver. Any unique reference number to identify the customer. Occupation of the customer. Date of Birth in YYYY-MM-DD format. Sex of the customer. Permissible values are: Gender M- Male F- Female X - Not Categorised. Refer section 12.1.9.1 for further details on enumerations. 1 No Length 80 10 50 10 Mandatory Yes No No No
108
Version 2.1
Element
Length
Mandatory
Nationality
Use two digit country codes as per ISO 3166. Refer Annexure F for Country codes. Use IN for India Document used for proof of identity. Permissible values are: A - Passport B - Election ID Card C - PAN Card D - ID Card E - Driving License F- Account Introducer G - UIDAI Letter H - NREGA job card Z Others Refer section 12.1.9.2 for further details on enumerations.
No
IdentificationType
No
Number mentioned in the identification document. Authority which had issued the identification document. Place where the document was issued. Ten digit PAN used by Income Tax Department. Use UIDAI number for individuals and any other unique identification number for legal entity (if available). Email address. Details of the customer address. Refer section 11.1.4.1 for details. Details of the customer phone. Refer section 11.1.4.2 for details.
No No No No No No Yes
Phone
Yes
109
Version 2.1
12.1.9.1 Enumeration for Gender Code M F X Description Male Female Not Categorised The information is not available. No category has been selected Remarks
12.1.9.2 Enumeration for IdentificationType Code A B C D E F G H Z Description Passport Election ID Card Pan Card ID Card Driving License Account Introducer UIDAI Letter NREGA job card Others Remarks Same code as used in version 1.0 Same code as used in version 1.0 Same code as used in version 1.0 Same code as used in version 1.0 Same code as used in version 1.0 Same code as used in version 1.0 Issued by the Unique Identification Authority of India (UIDAI) Signed by an officer of the State Government Same code as used in version 1.0
12.1.10 element Batch/Report/Transaction/CustomerDetails/CustomerAddress CustomerAddress provides information on the location, state and country of the customer. Figure: Overview of Customer Address
12.1.10.1 Type Address Refer section 11.1.4.1 for details. Financial Intelligence Unit India (FIU-IND)
110
Version 2.1
12.1.11 element Batch/Report/Transaction/CustomerDetails/Phone Refer section 11.1.4.2 for details. 12.1.12 element Batch/Report/Branch Branch provides information about the branch related to the transaction. Figure: Overview of Branch
111
Version 2.1
Table: Details of Branch Element Description Name of Institution relevant to the transactions. As there could be more than one branch/location relevant to the report, appropriate details should be provided in separate records. Name of the branch/location relevant to the transactions. Unique reference number to uniquely identify the branch/office of the institution where the transaction was conducted. InstitutionRefNum The number may be issued by the regulator/BIC/MICR/IFSC/self generated or other sources. Refer to earlier enumeration BranchRefNumType in section 11.1.10.1 for further details. Role of the Branch in the transaction. Permissible values are: A - Reporting entity itself B - Other than reporting entity X - Not categorised ReportingRole If the name of the branch/location of the entity is different from the reporting entity, the flag should be set as B. For Example: Report filed by a payment system provider would have flag as B in case of details of branch/location of other payment system participants. Bank identification code (BIC) of the branch as per ISO 9362 (if available) Details of the branch address. Refer section 11.1.4.1 for details. Details of the branch phone. Refer section 11.1.4.2 for details. Branch email id Any remark in respect of the branch/location 1 Yes 20 Yes Length Mandatory
InstitutionName
80
Yes
InstitutionBranchName
80
No
No Yes Yes No No
112
Version 2.1
12.1.12.1 Enumeration for ReportingRole Code A B Description Reporting entity itself Other than reporting entity Remarks The branch/location belongs to the reporting entity The branch/location belongs to an entity which is not the reporting entity The information is not available. selected No category has been
Not categorised
12.1.13 element Batch/Report/Branch/Address Refer section 11.1.4.1 for details. 12.1.14 element Batch/Report/Branch/Phone Refer section 11.1.4.2 for details.
113
Version 2.1
12.1.15 element Batch/Report/PaymentInstrument PaymentInstrument describes the instrument involved in the transaction
114
Version 2.1
Table: Details of PaymentInstrument Element InstrumentRefNum Description Instrument number such as card number used in transaction. Unique reference number of the institution that has issued the payment instrument/card. IssueInstitutionRefNum The number may be issued by the regulator/BIC/MICR/IFSC/self generated or other sources. Refer to earlier enumeration BranchRefNumType in section 11.1.10.1 for further details. Length Mandatory
20
Yes
20
No
InstrumentIssueInstitutionNam Name of institution which has issued the payment e instrument/card. InstrumentHolderName Name of person to whom the payment instrument was issued. Date of issue of payment instrument in YYYY-MMDD Format. Sum of all purchases in the payment Instrument/card from 1st April of the financial year till the last day of the month of reporting. If report is being furnished for Jan 2010 then transactions from 1st April 2009 to 31st Jan 2010 have to be aggregated. The amount should be rounded off to nearest rupee without decimal. For STRs generated in the middle of the month, the transactions upto generation of alert needs to be aggregated. Any remark in respect of the payment instrument/ card.
80
No
80
No
RelationshipBeginningDate
10
No
CumulativePurchaseTurnover
20
No
Remarks
20
No
115
Version 2.1
12.1.16 element Batch/Report/RelatedPersons RelatedPersons describes either the individual or the legal person associated with the transaction. Figure: Overview of Related Person
116
Version 2.1
Table: Details of RelatedPersons Element PersonName CustomerID Description Full name of the individual or the legal person/entity. Customer ID/Number. Relation of the person to the transaction. Permissible values are: A - Account Holder B - Authorised Signatory C - Proprietor/Director/Partner/Member of a legal entity D - Introducer E Guarantor F - Guardian N Nominee O - Beneficial Owner P - Proposer G - Assignee L - Life Assured J Beneficiary H Power of Attorney Z - Others X - Not Categorised. Refer section 12.1.16.1 for further details on enumerations. CommunicationAddress Phone Email SecondAddress PAN UIN Details of the persons communication address. Refer section 12.1.17 for details. Details of the persons phone. Refer section 12.1.18 for details. Contact email Details of the persons second or alternate address. Refer section 12.1.17 for details. Ten Digit PAN card number issued by Income Tax Department Use UIDAI number for individuals and any other unique identification number for legal entity (if available). Choice compositor. Choice Whether person is Individual or Legal Person. Section 12.1.17 Section 12.1.18 50 Section 12.1.17 10 30 Section 12.1.19 and 12.1.20 Yes No No No No No Length 80 10 Mandatory Yes No
RelationFlag
Yes
No
117
Version 2.1
12.1.16.1 Enumeration for RelationFlag Code Description A B C D E F N Account Holder Authorised Signatory Proprietor/Director/Partner/Member of a legal entity Introducer Guarantor Guardian Nominee Remarks Person in whose name the account stands Office or representative vested with the powers to commit the authorizing organisation to a binding agreement. Individuals linked to the legal entity in various capacities Person who introduced the account to the reporting entity A person who contracts to perform the promise, or discharge the liability, of a third person in case of his default. Person who operates the account on behalf of the minor E.g. Nominee as per section 45ZA of the BR act 1949, insurance etc. Beneficial owner i.e the natural person who ultimately owns or controls a client and or the person on whose behalf a transaction is being conducted, and includes a person who exercises ultimate effective control over a juridical person Insurance Companies Insurance Companies Insurance Companies Insurance Companies Written document conferring authority on the agent to perform certain acts or functions on behalf of the principal. Banks, Insurance and Intermediaries Not listed above (including non customer in case of attempted transactions) The information is not available. No category has been selected
Beneficial Owner
P G L J
Power of Attorney
Z X
12.1.17 element Batch/Report/RelatedPersons/CommunicationAddress The element has been explained in detail in section 11.1.4.1 12.1.18 element Batch/Report/RelatedPersons/Phone The element has been explained in detail in section 11.1.4.2
118
Version 2.1
12.1.19 element Batch/Report/RelatedPersons/Individual PersonDetails/Individual provides details of the individual and identification related information. Figure: Overview of Individual
119
Version 2.1
Element
Table: Details of RelatedPersons/Individual Description Sex of the individual Permissible values are: M - Male F- Female X Not Categorised. Refer section 12.1.9.1 for further details on enumerations. Mention the date of birth in YYYY-MM-DD format Document submitted as proof of identity of the individual Permissible values are: A - Passport B - Election Id Card C - Pan Card D - ID Card E - Driving License F - Account Introducer G - UIDAI Letter H - NREGA job card Z Others Refer section 12.1.9.2 for further details on enumerations. Number mentioned in the identification document Authority which had issued the identification document Place where document was issued Nationality of the person
Length
Mandatory
Gender
Yes
DateOfBirth
10
No
IdentificationType
Yes
20 20 20
No No No
Nationality
Mention the two digit Country code as per ISO 3166 standards. Refer Annexure F for Country Codes. Name of organisation/employer. Full name of father/spouse. Job of the individual
Yes
80 80 50
No No No
120
Version 2.1
12.1.19.1 Enumeration for Gender Code Description M F X Male Female Not Categorised The information is not available. No category has been selected Remarks
12.1.19.2 Enumeration for IdentificationType Code Description A B C D E F G H Z Passport Election ID Card Pan Card ID Card Driving License Account Introducer UIDAI letter NREGA job card Others Remarks Same as A used in version 1.0 Same as B used in version 1.0 Same as C used in version 1.0 Same as D used in version 1.0 Same as E used in version 1.0 Same as F used in version 1.0 Issued by the Unique Identification Authority of India (UIDAI) Signed by an officer of the State Government Not listed above
121
Version 2.1
12.1.20 element Batch/Report/RelatedPersons/LegalPerson LegalPerson provides information about Legal person or entity. Figure: Overview of LegalPerson
Element
Table: Details of RelatedPersons/LegalPersons Description Length Type of constitution of legal person/entity. Permissible values are: A - Sole Proprietorship B - Partnership Firm C - HUF D - Private Limited Company E- Public Limited Company F- Society
Mandatory
ConstitutionType
Yes
122
Version 2.1
Element
Description G - Association H - Trust I - Liquidator J - LLP Z - Others X Not Categorised. Refer section 12.1.20.1 for further details on enumerations.
Length
Mandatory
Registration Number as mentioned in the document Date of incorporation in YYYY-MM-DD format Place where the document was registered. The two digit country code in which the entity is incorporated. Mention country code as per ISO 3166. Refer Annexure F for country codes. Nature of Business
20 10 20
No Yes No
CountryCode
Yes
NatureOfBusiness
50
No
12.1.20.1 Enumeration for ConstitutionType Code Description A B C D E F G H I J Z X Sole Proprietorship Partnership Firm HUF Private Limited Company Public Limited Company Society Association Trust Liquidator LLP Others Not Categorised Limited Liability Partnership Not listed above The information is not available. No category has been selected Hindu Undivided Family Remarks
123
Version 2.1
12.2.1 Data structure of Batch File (TRFBAT.txt) S. No. Field Type Size From To Remarks Running sequence number for each line in the file starting from 1. This number will be used during validation checks. Refer section 12.1.1 Refer section 12.1.2 Refer section 12.1.3 Refer section 12.1.3 Refer section 12.1.3 Refer section 12.1.3 Refer section 12.1.4 Refer section 12.1.4 Refer section 12.1.4 Mapping to version 1.0
Line Number*
NUM
Line Number* Report Name Data Structure Version* Complete name of Entity* Category of Entity* Regulator Issued code * Unique ID issued by FIU* Principal Officers Name* Principal Officers Designation* Principal Officers Address*
2 3 4 5 6 7 8 9 10
3 1 80 5 12 10 80 80 225
ReportingEntityCategory* CHAR RERegistrationNumber FIUREID* POName* PODesignation* Address* CHAR CHAR CHAR CHAR CHAR
124
Version 2.1
S. No. 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
Field City StateCode* PinCode CountryCode* Telephone Mobile Fax POEmail BatchNumber* BatchDate* MonthOfReport* YearOfReport* OperationalMode* BatchType* OriginalBatchId* ReasonOfRevision*
Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR NUM CHAR
Size 50 2 10 2 30 30 30 50 8 10 2 4 1 1 10 1
From 503 553 555 565 567 597 627 657 707 715 725 727 731 732 733 743
To 552 554 564 566 596 626 656 706 714 724 726 730 731 732 742 743
Remarks Refer section 12.1.4 Refer section 12.1.4 Refer section 12.1.4 Refer section 12.1.4 Refer section 12.1.4 Refer section 12.1.4 Refer section 12.1.4 Refer section 12.1.4 Refer section 12.1.5 Refer section 12.1.5 Refer section 12.1.5 Refer section 12.1.5 Refer section 12.1.5 Refer section 12.1.5 Refer section 12.1.5 Refer section 12.1.5
Mapping to version 1.0 Principal Officers City New field Principal Officers Pin code* Principal Officers Country Code* Principal Officers Telephone New field Principal Officers FAX Principal Officers Email Serial Number of Report* Date of Report Specified only in CTR Specified only in CTR Operational Mode* Report Type* Serial Number of Original Report * Reason for Replacement*
12.2.2 Data structure of Report File (TRFRPT.txt) S. No. Field Type Size From To Remarks Running sequence number for each line in the file starting from 000001. This Number will be used during validation checks. Refer section 12.1.6 Refer section Mapping to Version 1.0
LineNumber*
NUM
Line Number*
2 3
ReportSerialNum* OriginalReportSerialNum*
NUM NUM
8 8
7 15
14 22
125
Version 2.1
S. No.
Field
Type
Size
From
To
Remarks 12.1.6
4 5 6 7 8 9
Refer section 12.1.6 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7 Refer section 12.1.7
New field New field New field New field New field Suspicion of proceeds of crime Suspicion due to unusual or complex transactions Suspicion due to no economic rationale or bonafide purpose Suspicion of financing of terrorsim New field Grounds of Suspicion* Details of other investigations Correspondence to/from Law Enforcement Agency New field Priority Rating Report Coverage New field
10
SuspicionDueToComplexTrans*
CHAR
406
406
11
SuspicionDueToNoEcoRationale*
CHAR
407
407
12 13 14 15
1 1 4000 4000
16
LEAInformed*
CHAR
8410
8410
17 18 19 20
250 2 1 1
126
Version 2.1
12.2.3 Data structure of Branch File (TRFBRC.txt) S. Field No. Type Size From To Remarks Running sequence number for each line in the file starting from 0000001. This number will be used during validation checks. Mapping to Version 1.0
Line Number*
NUM
Line Number*
2 3 4 5 6 7 8 9 10 11 12 13 14 15
InstitutionName* InstitutionBranchName InstitutionRefNum* BIC Address* City StateCode* PinCode CountryCode* Telephone Mobile Fax Email Remarks
CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
80 80 20 11 225 50 2 10 2 30 30 30 50 30
7 87 167 187 198 423 473 475 485 487 517 547 577 627
86 166 186 197 422 472 474 484 486 516 546 576 626 656
Refer section 12.1.12 Institution Name* Refer section 12.1.12 Institution Branch Name* Institution Refer section 12.1.12 Reference Number* Refer section 12.1.12 BIC of the branch Refer section 12.1.13 Branch Address* Refer section 12.1.13 Branch City Refer section 12.1.13 New field Refer section 12.1.13 Branch Pin code/ZIP code* Refer section 12.1.13 Branch Country Code* Refer section 12.1.14 Branch Telephone Refer section 12.1.14 New field Refer section 12.1.14 Branch Fax Refer section 12.1.12 Branch E-mail Refer section 12.1.12 Branch Remarks
12.2.4 Data structure of Transaction File (TRFTRN.txt) S. No. Field Type Size From To Remarks Running sequence number for each line in the file starting from 1. This number will be used during validation checks. Mapping to Version 1.0
Line Number*
NUM
Line Number*
127
Version 2.1
S. No. 2 3 4 5 6 7 8
Size 8 10 8 20 1 1 80
From 7 15 25 33 53 54 55
To 14 24 32 52 53 54 134
Remarks Refer section 12.1.6 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8
Mapping to Version 1.0 STR Reference Number * Transaction Date * Transaction Time Transaction Reference Number Transaction Type* Instrument Type * Transaction Institution Name* Transaction Institution Reference Number* Transaction State Code Transaction Country Code* Payment Instrument Number Payment Instrument Issue Institution Name Payment Instrument Issue Institution Reference Number Payment Instrument Country Code Amount in Rupees* Amount in Foreign Currency Unit Currency of Transaction* Purpose of transaction*
TransactionInstitutionRefNum*
CHAR
20
135
154
10 11 12
2 2 20
13
PaymentInstrumentIssueInstituteName
CHAR
80
179
258
14
InstrumentIssueInstitutionRefNum
CHAR
20
259
278
Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8
15 16 17 18 19
2 20 20 3 100
128
Version 2.1
S. No. 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
Field PurposeCode RiskRating* CustomerName* CustomerId Occupation DateOfBirth Gender Nationality IdentificationType IdentificationNumber IssuingAuthority PlaceOfIssue PAN UIN Address* City StateCode* PinCode CountryCode* Telephone Mobile Fax
Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
Size 5 2 80 10 50 10 1 2 1 20 20 20 10 30 225 50 2 10 2 30 30 30
From 424 429 431 511 521 571 581 582 584 585 605 625 645 655 685 910 960 962 972 974 1004 1034
To 428 430 510 520 570 580 581 583 584 604 624 644 654 684 909 959 961 971 973 1003 1033 1063
Remarks Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.9 Refer section 12.1.10 Refer section 12.1.10 Refer section 12.1.10 Refer section 12.1.10 Refer section 12.1.10 Refer section 12.1.11 Refer section 12.1.11 Refer section 12.1.11
Mapping to Version 1.0 Purpose Code Risk Category Customer Name* Customer Reference Number Occupation Date of Birth Sex Nationality ID Type ID Number ID Issuing Authority ID Issue Place PAN New field Address* City New field Address Pin code/ZIP code* Address Country Code Telephone Mobile number New field
129
Version 2.1
S. No. 42 43 44
Size 50 20 80
Remarks Refer section 12.1.9 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8 Refer section 12.1.8
Mapping to Version 1.0 E-mail Account Number Account With Institution Name Account With Institution Reference Number Related Institution Name Institution Relation Flag Related Institution Reference Number Transaction Remarks
45
AccountWithInstitutionRefNum
CHAR
20
1214
1233
46 47
RelatedInstitutionName InstitutionRelationFlag
CHAR CHAR
80 1
1234 1314
1313 1314
48
RelatedInstitutionRefNum
CHAR
20
1315
1334
49
Remarks
CHAR
50
1335
1384
12.2.5 Data structure of Payment Instrument File (TRFPIN.txt) S. Field No. Type Size From To Remarks Mapping to Version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting Same from 1. This number will be used during validation checks. Refer section 12.1.6 Refer section 12.1.15 Refer section 12.1.15 Refer section 12.1.15 Refer section 12.1.15 Refer section 12.1.15 Refer section 12.1.15 STR Reference Number * Payment Instrument Reference Number* Institution Reference Number* Institution Name* Payment Instrument Holder Name Relationship Beginning Date Cumulative Purchase Turnover
2 3 4 5 6 7 8
8 20 20 80 80 10 20
130
Version 2.1
Type CHAR
Size 30
From 245
To 274
12.2.6 Data structure of Individual Person File (TRFINP.txt) S. Field No Type Size From To Remarks Mapping to Version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from Line Number* 000001. This number will be used during validation checks. Refer section 12.1.6 Refer section 12.1.16 Refer section 12.1.16 Refer section 12.1.16 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.18 Refer section 12.1.18 Refer section 12.1.18 Refer section 12.1.16 Refer section 12.1.16 Refer section 12.1.16 STR Reference Number * Full name of Individual* Customer ID/Number Relation Flag* Communication Address* Communication City New field Communication Address Pin code/Zip code* Communication Country Code New field New field New field New field New field Contact Telephone Contact Mobile number New field Contact E-mail PAN New field
2 3 4 5 6 7 8 9
NUM CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
8 80 10 1 225 50 2 10 2 225 50 2 10 2 30 30 30 50 10 30
7 15 95 105 106 331 381 383 393 395 620 670 672 682 684 714 744 774 824 834
14 94 104 105 330 380 382 392 394 619 669 671 681 683 713 743 773 823 833 863
10 CountryCode* 11 Second Address 12 City 13 StateCode* 14 PinCode 15 CountryCode* 16 Telephone 17 Mobile 18 Fax 19 Email 20 PAN 21 UIN
131
Version 2.1
S. Field No 22 Gender* 23 DateOfBirth 24 IdentificationType 25 IdentificationNumber 26 IssuingAuthority 27 PlaceOfIssue 28 Nationality* 29 PlaceOfWork 30 FatherOrSpouse 31 Occupation
Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
Size 1 10 1 20 20 20 2 80 80 50
From 864 865 875 876 896 916 936 938 1018 1098
To 864 874 875 895 915 935 937 1017 1097 1147
Remarks Refer section 12.1.19 Refer section 12.1.19 Refer section 12.1.19 Refer section 12.1.19 Refer section 12.1.19 Refer section 12.1.19 Refer section 12.1.19 Refer section 12.1.19 Refer section 12.1.19 Refer section 12.1.19
Mapping to Version 1.0 Sex Date of Birth Type of Identification Identification Number Issuing Authority Place of Issue Nationality Place of Work Name of Father/Spouse Occupation
12.2.7 Data structure of Legal Person Entity File (TRFLPE.txt) S. No . Field Type Size From To Remarks Running sequence number for each line in the file starting from 000001. This number will be used during validation checks. Refer section 12.1.6 Refer section 12.1.16 Refer section 12.1.16 Refer section 12.1.16 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Refer section 12.1.17 Mapping to Version 1.0
Line Number*
NUM
Line Number*
2 3 4 5 6 7 8 9 10 11 12 13 14 15
ReportSerialNum* PersonName* CustomerId RelationFlag* Communication Address* City StateCode* PinCode CountryCode* Second Address City StateCode* PinCode CountryCode*
NUM CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
8 80 10 1 225 50 2 10 2 225 50 2 10 2
7 15 95 105 106 331 381 383 393 395 620 670 672 682
14 94 104 105 330 380 382 392 394 619 669 671 681 683
STR Reference Number * Name of Legal Person /Entity* Customer ID/Number Relation Flag* Communication Address* Communication City New field Communication Address Pin code/ZIP code* Communication Country Code New field New field New field New field New field
132
Version 2.1
S. No . 16 17 18 19 20 21 22 23 24 25 26 27
Field Telephone Mobile Fax Email PAN UIN ConstitutionType* RegistrationNumber DateOfIncorporation PlaceOfRegistration CountryCode* NatureOfBusiness
Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
Size 30 30 30 50 10 30 1 20 10 20 2 50
From 684 714 744 774 824 834 864 865 885 895 915 917
To 713 743 773 823 833 863 864 884 894 914 916 966
Remarks Refer section 12.1.18 Refer section 12.1.18 Refer section 12.1.18 Refer section 12.1.16 Refer section 12.1.16 Refer section 12.1.16 Refer section 12.1.20 Refer section 12.1.20 Refer section 12.1.20 Refer section 12.1.20 Refer section 12.1.20 Refer section 12.1.20
Mapping to Version 1.0 Contact Telephone Contact Mobile number Contact Fax Contact E-mail PAN New field Type of Constitution* Registration Number Date of Incorporation Place of Registration New field Nature of Business
133
Version 2.1
134
Version 2.1
S. No. 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46
Element Batch / Report / Transaction / TransactionType Batch / Report / Transaction / InstrumentType Batch / Report / Transaction / TransactionStateCode Batch / Report / Transaction / TransactionCountryCode Batch / Report / Transaction / InstrumentCountryCode Batch / Report / Transaction / CurrencyOfTransaction Batch / Report / Transaction / PurposeCode Batch / Report / Transaction / RiskRating Batch / Report / Transaction / CustomerDetails / Gender Batch / Report / Transaction / CustomerDetails / Nationality Batch / Report / Transaction / CustomerDetails / IdentificationType Batch / Report / Transaction / CustomerDetails / CustomerAddress / StateCode Batch / Report / Transaction / CustomerDetails / CustomerAddress / CountryCode Batch / Report / Transaction / InstitutionRelationFlag Batch / Report / Branch / ReportingRole Batch / Report / BranchAddress / Address / StateCode Batch / Report / BranchAddress / Address / CountryCode Batch / Report / RelatedPersons / RelationFlag Batch / Report / RelatedPersons / CommunicationAddress / StateCode Batch / Report / RelatedPersons / CommunicationAddress / CountryCode Batch / Report / RelatedPersons / Individual / Gender Batch / Report / RelatedPersons / Individual / IdentificationType Batch / Report / RelatedPersons / Individual / Nationality Batch / Report / RelatedPersons / LegalPerson / ConstitutionType Batch / Report / RelatedPersons / LegalPerson / CountryCode
Section Section 12.1.8.1 Section 12.1.8.2 Annexure E Annexure F Annexure F Annexure G Refer RBI Purpose codes Section 12.1.8.3 Section 12.1.9.1 Annexure F Section 12.1.9.2 Annexure E Annexure F Section 12.1.8.4 Section 12.1.12.1 Annexure E Annexure F Section 12.1.16.1 Annexure E Annexure F Section 12.1.19.1 Section 12.1.19.2 Annexure F Section 12.1.20.1 Annexure F
135
Version 2.1
12.3.2 Mandatory Validation Rule Matrix In addition to the enumerations, the validations for mandatory elements will be conducted by schema level validation and rule based validation. The mandatary value is being specified at following levels: MandatoryValue in XSD Rule based (Fatal) (Specifed as MandatoryValueFatal) Rule based (Non Fatal (Specifed as MandatoryValueNonFatal)
The rules for validation will be specified in the external rule file (SCH format) which could be revised from time to time. The sample matrix of the mandatory validation is as under: Rule based (Non Fatal)
S. No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Element
Batch / ReportingEntity / ReportingEntityName Batch / ReportingEntity / ReportingEntityCategory Batch / ReportingEntity / RERegistrationNumber Batch / ReportingEntity / FIUREID Batch / PrincipalOfficer / POName Batch / PrincipalOfficer / PODesignation Batch / PrincipalOfficer / POAddress / Address Batch / PrincipalOfficer / POAddress / PinCode Batch / PrincipalOfficer / POPhone / Telephone Batch / PrincipalOfficer / POPhone / Mobile Batch / PrincipalOfficer / POPhone / Fax Batch / PrincipalOfficer / POEmail Batch / BatchDetails / BatchNumber Batch / BatchDetails / BatchDate Batch / BatchDetails / OriginalBatchID Batch / Report / ReportSerialNum Batch / Report / OriginalReportSerialNum Batch / Report / MainPersonName Batch / Report / SuspicionDetails / GroundsOfSuspicion
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
136
Version 2.1
S. No.
Element
20 21 22 23 24 25 26 27 28 29 30
Batch / Report / SuspicionDetails / DetailsOfInvestigations Batch / Report / Transaction / TransactionDate Batch / Report / Transaction / TransactionInstitutionName Batch / Report / Transaction / TransactionInstitutionRefNum Batch / Report / Transaction / AmountRupees Batch / Report / Transaction / AmountForeignCurrency Batch / Report / Transaction / PurposeOfTransaction Batch / Report / Branch / InstitutionName Batch / Report / Branch / InstitutionRefNum Batch / Report / BranchAddress / Address / Address Batch / Report / BranchAddress / Address / PinCode Y Y Y Y Y Y Y Y Y
137
Version 2.1
12.3.3 Other rules for Preliminary Rule Validation (PRV) In addition to the enumeration and mandatory validations, rules will also be specified in the external rule file (SCH format) which could be revised from time to time. Explanation of sample rules is as under: S. No. 1 2 3 4 5 Element Batch / PrincipalOfficer / POAddress / Address Batch / PrincipalOfficer / POPhone / Telephone Batch / PrincipalOfficer / POPhone / Mobile Batch / PrincipalOfficer / POEmail Batch / BatchDetails / BatchDate Validation Rule Type SufficiencyLengthNonFatal SufficiencyLengthNonFatal SufficiencyLengthNonFatal SufficiencyLengthNonFatal ConsistencyValue Rule Length should minimum 8 Length should minimum 6 Length should minimum 6 Length should minimum 6 be be be be
Value should be earlier than system date Value is earlier than one year from system date. Value is NA for CTR Value is NA for CTR Value in a batch should be unique If ReportType is STR, at least one "SuspicionDetail" element should be present for each report Length should minimum 8 Length should minimum 8 Length should minimum 8 Length should minimum 5 Length should minimum 5 be be be be be
6 7 8 9
Batch / BatchDetails / BatchDate Batch / BatchDetails / MonthOfReport Batch / BatchDetails / YearOfReport Batch / Report / ReportSerialNum
10
SufficiencyElementFatal
11 12 13 14 15 16
Batch / Report / Transaction / CustomerDetails / CustomerAddress / Address Batch / Report / BranchAddress / Address / Address Batch / Report / RelatedPersons CommunicationAddress / Address /
Batch / Report / Transaction / CustomerDetails / IdentificationNumber Batch / Report / RelatedPersons / Individual / IdentificationNumber Batch / Report / Transaction / TransactionDate
138
Version 2.1
S. No.
Element
17
Batch / Report / Transaction / TransactionDate Batch / Report / Transaction / CustomerDetails / DateOfBirth Batch / Report / RelatedPersons / Individual / DateOfBirth Batch / Report / RelatedPersons / LegalPerson / DateOfIncorporation Batch / Report / Transaction / AmountRupees
ConsistencyValue
Value should not be earlier than one year from system date Value should be earlier than system date Value should be earlier than system date Value should be earlier than system date Value of a single cash transaction exceeds 1billion INR
18 19 20
21
ErrorProbablityMedium
12.3.4 Sample Rules for Advanced Rule Validation (ARV) The rules for Advanced Rule Validation (ARV) will be specified in the internal system of FIU. Explanation of sample rules is as under: S. No. 1 Element Batch / Report / Transaction / CustomerDetails / CustomerAddress / Address Batch / Report / Branch / BranchDetails / BranchAddress / Address Batch / Report / Branch / BranchDetails / BranchAddress / PinCode Batch / Report / Transaction / CustomerDetails / CustomerAddress / PinCode Batch / Report / Transaction / CustomerDetails / PAN Validation Rule Type SufficiencyValue Explanation The address should contain sufficient information (dictionary based) The address should contain sufficient information (dictionary based) The pincode of the branch should match with the pincode dictionary The pincode of the customer should match with the pincode dictionary The PAN of the customer should be a valid PAN in Income Tax Database
SufficiencyValue
ConsistencyValueInternalSource
ConsistencyValueInternalSource
ConsistencyValueExternalSource
139
Version 2.1
13.1.6 element Batch/Report Report element provides details of the Reports in the batch. The Reports are uniquely identified by the ReportSerialNum.
140
Version 2.1
Element ReportSerialNum
Table: Details of Batch/Reports Description The report serial number should be unique within a batch. Indicates the report serial number of the original report that has to be replaced or deleted.
Length 8
Mandatory Yes
OriginalReportSerialNum
In case there is no replacement or deletion of any original report, mention 0 here. Details of the branch. Refer section 13.1.7 for details. Details of the incident. Refer section 13.1.11 for details. Details of the fake currency notes tendered. Refer section 13.1.12 for details.
Yes
Yes No Yes
141
Version 2.1
13.1.7 element Batch/Report/Branch Branch provides information about the branch where counterfeit currency was detected. The element has been explained in section 11.1.10 13.1.7.1 Enumeration for BranchRefNumType The BranchRefNumType is the unique code used to identify the branch. The element has been explained in section 11.1.10.1 13.1.8 element Batch/Report/Branch/BranchDetails BranchDetails provides information about the branch. The element has been explained in section 11.1.11. 13.1.9 element Batch/Report/Branch/BranchDetails/BranchAddress The element has been explained in section 11.1.12 13.1.10 element Batch/Report/Branch/BranchDetails/BranchPhone The element has been explained in section 11.1.13
142
Version 2.1
13.1.11 element Batch/Report/ReportSummary ReportSummary provides information on the summary of counterfeit currency detected in one incident. Figure: Overview of Report Summary
143
Version 2.1
Table: Details of Report Summary Element INR1000NoteCount INR500NoteCount INR100NoteCount INR50NoteCount INR20NoteCount INR10NoteCount INR5NoteCount Description Number of counterfeit currency notes of denomination Rs. 1000. Enter 0 if not applicable Number of counterfeit currency notes of denomination Rs. 500. Enter 0 if not applicable Number of counterfeit currency notes of denomination Rs. 100. Enter 0 if not applicable Number of counterfeit currency notes of denomination Rs. 50. Enter 0 if not applicable Number of counterfeit currency notes of denomination Rs. 20. Enter 0 if not applicable Number of counterfeit currency notes of denomination Rs. 10. Enter 0 if not applicable Number of counterfeit currency notes of denomination Rs. 5. Enter 0 if not applicable Total Counterfeit Currency detected in the incident. FICNValue This value should match with the value derived from the number of notes mentioned above. Date of tendering of counterfeit currency in YYYY-MM-DD format, if available. For Example: 28th May 2010 should be written in YYYY-MM-DD i.e., 2010-05-28 Total value of cash tendered (including the counterfeit currency), if available Date of detection of counterfeit currency in YYYY-MM-DD format if available Point of detection of fake currency. Permissible values are: DetectedAt A- Cash Counter B- Branch Level C-Currency Chest D- RBIs CVPS Z- Others Refer section 13.1.11.1 for further details on enumerations. Whether police was informed Permissible values are: PoliceInformed Y Yes N No X Not Categorised. Refer section 13.1.11.2 for further details on enumerations. 1 Yes 1 Yes 10 Yes Length 10 10 10 10 10 10 5 Mandatory Yes Yes Yes Yes Yes Yes Yes
DateofTendering
10
No
CashTendered DateofDetection
20 10
No Yes
144
Version 2.1
Description Details of FIR, Police Station etc., if available Person who tendered the counterfeit currency, if available. Name of the Sole/First account holder in whose account the counterfeit currency was tendered, if available. Account/Card number of the person in whose account the counterfeit currency was tendered, if available. Priority attached to the report as per assessment of the reporting entity. Permissible values are: P1- Very High Priority P2- High Priority P3- Normal Priority XX- Not categorised The reporting entity can attach P1 priority for reports which requires immediate attention of FIU. Refer section 13.1.11.3 for further details on enumerations.
Length 80 80 80 20
Mandatory No No No No
PriorityRating
Yes
IncidentRemarks
Remarks
50
No
13.1.11.1 Enumeration for DetectedAt Code Description A B C D Z Cash Counter Branch Level Currency Chest RBIs CVPS Others Not listed above Remarks
13.1.11.2 Enumeration for PoliceInformed This enumeration provides details of Police informed if yes, no or not categorised. 13.1.11.3 Enumeration for PriorityRating Code Description P1 P2 P3 XX Very High Priority High Priority Normal Priority Not Categorised Remarks For immediate attention by FIU For attention of FIU Reasonable time The information is not available. No category has been selected
145
Version 2.1
13.1.12 element Batch/Report/TransactionDetails TransactionDetails describes details of the note with serial number. This element is optional Figure: Overview of Transaction Details
Table: TransactionDetails Element Denomination CurrencySerialNum CurrencyRemarks Description Currency denomination Refer 13.1.12.1 for details on enumeration The Currency serial number of the counterfeit note Currency remarks Length 4 15 50 Mandatory Yes Yes No
13.1.12.1 Enumeration for Denomination Code Description 1000 500 100 50 20 10 5 1000 Rupee note 500 Rupee note 100 Rupee note 50 Rupee note 20 Rupee note 10 Rupee note 5 Rupee note Remarks
146
Version 2.1
13.2.1 Data structure of Batch File (CRFBAT.txt) S. Field No. Type Size From To Remarks Mapping to version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from Line Number* 000001. This number will be used during validation checks. Refer section 13.1.1 Refer section 13.1.2 Refer section 13.1.3 Refer section 13.1.3 Refer section 13.1.3 Refer section 13.1.3 Refer section 13.1.4 Refer section 13.1.4 Report Name Data Structure Version* Complete name of Entity* Category of Entity* Regulator Issued code * Unique ID issued by FIU* Principal Officers Name* Principal Officers Designation* Principal Officers Address1* + Address2 + Address3 + Address 4 + Address5 New field New field
2 3 4 5 6 7 8 9
3 1 80 5 12 10 80 80
10 11 12
225 50 2
147
Version 2.1
S. Field No. 13 14 15 16 17 18 19 20 21 22 23 24 25 26 PinCode CountryCode* Telephone Mobile Fax POEmail BatchNumber* BatchDate* MonthOfReport* YearOfReport* OperationalMode* BatchType* OriginalBatchId* ReasonOfRevision*
Type CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR NUM CHAR
Size 10 2 30 30 30 50 8 10 2 4 1 1 10 1
From 555 565 567 597 627 657 707 715 725 727 731 732 733 743
To 564 566 596 626 656 706 714 724 726 730 731 732 742 743
Remarks Refer section 13.1.4 Refer section 13.1.4 Refer section 13.1.4 Refer section 13.1.4 Refer section 13.1.4 Refer section 13.1.4 Refer section 13.1.5 Refer section 13.1.5 Refer section 13.1.5 Refer section 13.1.5 Refer section 13.1.5 Refer section 13.1.5 Refer section 13.1.5 Refer section 13.1.5
Mapping to version 1.0 Principal Officers Pin code* New field Principal Officers Telephone New field Principal Officers FAX Principal Officers Email Serial Number of Report* Date of Report New field New field Operational Mode* Report Type* Serial Number of Original Report * Reason for Replacement*
13.2.2 Data structure of Report File (CRFRPT.txt) S. Field No. Type Size From To Remarks Mapping to version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from Line Number* 1. This number will be used during validation checks. Refer section 13.1.6 Refer section 13.1.6 Refer section 13.1.7 New field New field Branch Reference Number*
2 3 4 5 6 7
8 8 20 10 10 10
7 15 23 43 53 63
14 22 42 52 62 72
Refer section 13.1.11 Denomination1000* Refer section 13.1.11 Denomination500* Refer section 13.1.11 Denomination100*
148
Version 2.1
Type NUM NUM NUM NUM NUM CHAR NUM CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR CHAR
Size 10 10 10 10 10 10 20 10 1 1 80 80 80 20 2 50
From 73 83 93 103 113 123 133 153 163 164 165 245 325 405 425 427
To 82 92 102 112 122 132 152 162 163 164 244 324 404 424 426 476
Remarks
Refer section 13.1.11 Denomination50* Refer section 13.1.11 Denomination20* Refer section 13.1.11 Denomination10* Refer section 13.1.11 Denomination5* Refer section 13.1.11 Total Counterfeit Currency*
10 INR10NoteCount* 11 INR5NoteCount* 12 FICNValue* 13 DateOfTendering 14 CashTendered 15 DateOfDetection* 16 DetectedAt* 17 PoliceInformed* 18 PoliceReportDetail 19 TenderingPerson 20 AccountHolder 21 AccountNumber 22 PriorityRating* 23 IncidentRemarks
Refer section 13.1.11 Tendering Date Refer section 13.1.11 Total Cash Tendered Refer section 13.1.11 Detection Date* Refer section 13.1.11 Detected At* Refer section 13.1.11 Police Informed* Refer section 13.1.11 Police Report Detail Refer section 13.1.11 Refer section 13.1.11 Name of Tendering Person Name of Account Holder
Refer section 13.1.11 Account Number Refer section 13.1.11 New field Refer section 13.1.11 New field
13.2.3 Data structure of Branch File (CRFBRC.txt) S. Field No. Type Size From To Remarks Mapping to version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from 1. This number will be used during validation Line Number* checks. Refer section 13.1.7 New field
BranchRefNumType*
CHAR
149
Version 2.1
Size 20 80
From 8 28
To 27 107
Mapping to version 1.0 Branch Reference Number* Name of Branch* Branch Address1* + Address2 + Address3 + Address4 + Address5 New field New field Branch Pin code* New field Branch Telephone New field Branch Fax Branch E-mail
Address*
CHAR
225
108
332
6 7 8 9
50 2 10 2 30 30 30 50
Refer section 13.1.9 Refer section 13.1.9 Refer section 13.1.9 Refer section 13.1.9 Refer section 13.1.10 Refer section 13.1.10 Refer section 13.1.10 Refer section 13.1.8
13.2.4 Data structure of Transaction File (CRFTRN.txt) S. Field No. Type Size From To Remarks Mapping to Version 1.0
Line Number*
NUM
Running sequence number for each line in the file starting from New field 1. This number will be used during validation checks. Refer section 13.1.6 Refer section 13.1.12 Refer section 13.1.12 Refer section 13.1.12 New field New field New field New field
2 3 4 5
8 4 15 50
7 15 19 34
14 18 33 83
150
Version 2.1
151
Version 2.1
13.3.2 Mandatory Validation Rule Matrix In addition to the enumerations, the validations for mandatory elements will be conducted by schema level validation and rule based validation. The mandatary value is being specified at following level MandatoryValue in XSD Rule based (Fatal) (Specifed as MandatoryValueFatal) Rule based (Non Fatal (Specifed as MandatoryValueNonFatal)
The rules for validation will be specified in the external rule file (SCH format) which could be revised from time to time. The sample matrix of the mandatory validation is as under:
S. No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
XML Tag Batch / ReportingEntity / ReportingEntityName Batch / ReportingEntity / RERegistrationNumber Batch / ReportingEntity / FIUREID Batch / PrincipalOfficer / POName Batch / PrincipalOfficer / PODesignation Batch / PrincipalOfficer / POAddress / Address Batch / PrincipalOfficer / POAddress / PinCode Batch / PrincipalOfficer / POPhone / Telephone Batch / PrincipalOfficer / POPhone / Mobile Batch / PrincipalOfficer / POPhone / Fax Batch / PrincipalOfficer / POEmail Batch / BatchDetails / BatchNumber Batch / BatchDetails / BatchDate Batch / Report / ReportSummary / INR1000NoteCount Batch / Report / ReportSummary / INR500NoteCount Batch / Report / ReportSummary / INR100NoteCount Batch / Report / ReportSummary / INR50NoteCount Batch / Report / ReportSummary / INR20NoteCount Batch / Report / ReportSummary / INR10NoteCount Batch / Report / ReportSummary / INR5NoteCount
Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y
152
Version 2.1
S. No. 21 22 23
XML Tag Batch / Report / ReportSummary / FICNValue Batch / Report / ReportSummary / CashTendered Batch / Report / ReportSummary / DateOfDetection
Y Y
13.3.3 Other rules for Preliminary Rule Validation (PRV) In addition to the enumeration and mandatory validations, rules will also be specified in the external rule file (SCH format) which could be revised from time to time. Explanation of sample rules is as under: S. No. 1 2 4 5 6 7 8 9 10 11 12 13 14 15 16 Element Batch / PrincipalOfficer / POAddress / Address Batch / PrincipalOfficer / POPhone / Telephone Batch / PrincipalOfficer / POPhone / Mobile Batch / PrincipalOfficer / POEmail Batch / BatchDetails / BatchDate Batch / BatchDetails / BatchDate Batch / BatchDetails / MonthOfReport Batch / BatchDetails / YearOfReport Batch / Report / ReportSerialNum Batch / Report / Branch / BranchDetails / BranchAddress / Address Batch / Report / ReportSummary / FICNValue Batch / Report / ReportSummary / DateOfTendering Batch / Report / ReportSummary / CashTendered Batch / Report / ReportSummary / DateOfDetection Batch / Report / ReportSummary / DateOfDetection Batch / Report / TransactionDetails / Denomination Batch / Report / ReportSummary / DateOfTendering Batch / Report / ReportSummary / DateOfDetection Validation Rule Type SufficiencyLengthNonFatal SufficiencyLengthNonFatal SufficiencyLengthNonFatal SufficiencyLengthNonFatal ConsistencyValue ErrorProbablityHigh ErrorProbablityHigh ErrorProbablityHigh UniqueValue SufficiencyLengthNonFatal ConsistencySum ConsistencyValue ConsistencyValue ConsistencyValue ConsistencyValue Explanation Length should be minimum 8 Length should be minimum 6 Length should be minimum 6 Length should be minimum 6 Value should be earlier than current date Value is earlier than one year from current date Value should be NA Value should be NA Value should be unique in a batch Length should be minimum 8 Value should equal sum of values derived from all Note Count elements. Value should be earlier than system date Cash tendered should not be less than FICN Value Value should be earlier than system date. Value should be greater than date of tendering Number of tags with a particular denomination should not be greater than the value in report summary details Value is earlier than one year from current date. Value is earlier than one year from current date
17
ConsistencyValue
18 19
ErrorProbablityHigh ErrorProbablityHigh
153
Version 2.1
13.3.4 Sample Rules for Advanced Rule Validation (ARV) The rules for Advanced Rule Validation (ARV) will be specified in the internal system of FIU. Explanation of sample rules is as under: S. No. 1 Element Batch / Report / Account / Branch / BranchDetails / BranchAddress / Address Batch / Report / Account / Branch / BranchDetails / BranchAddress / PinCode Validation Rule Type SufficiencyValue Explanation The address should contain sufficient information (dictionary based) The pincode of the branch should match with the pincode dictionary
ConsistencyValueInternalSource
154
Version 2.1
Table: Details of DataQualityReport Element Description Type of report in the batch. Permissible values are: CTR - Cash Transaction Report STR - Suspicious Transaction Report NTR - NPO Transaction Report CCR - Counterfeit Currency Report One DataQualityReport batch contains error details of one batch. One batch can have only one type of report. Type of reporting format in the batch. Permissible values are: ARF Account based reporting format TRF Transaction based reporting format CRF Counterfeit currency based reporting format One batch can contain only one prescribed type of reporting format. Refer section 11.1.1.2 for further details on enumerations. BatchHeader ReportingEntity Details of the Batch Type and other version information. Refer section 11.1.2 for details Details of the Reporting Entity. Refer section 11.1.3 for details Section 11.1.2 Section 11.1.3 Yes Yes Length Mandatory
ReportType
Yes
ReportFormatType
Yes
155
Version 2.1
Description Details of the Principal Officer. Refer section 11.1.4 for details Details of the Batch of reports. Refer section 11.1.5 for details Summary of the uploaded batch. Refer section 14.1.6 for details.
Length Section 11.1.4 Section 11.1.5 Section 14.1.6 Section 14.1.13 Section 14.1.18
Details of batch level and report level errors after prelimnary PreliminaryValidation rule validation (PRV). Refer section 14.1.13 for details. AdvancedValidation Details of batch level and report level errors after advanced rule validation (ARV). Refer section 14.1.17 for details.
Yes
14.1.2 element DataQualityReport/BatchHeader The element BatchHeader contains information about the types of reports in the batch and version information. Refer section 11.1.2 for details. 14.1.3 element DataQualityReport/ReportingEntity The element ReportingEntity contains information about the reporting entity which submitted the report batch. Refer section 11.1.3 for details. 14.1.4 element DataQualityReport/PrincipalOfficer The element PrincipalOfficer contains information about the principal officer of the reporting entity. Refer section 11.1.4 for details. 14.1.5 element DataQualityReport/BatchDetails The element BatchDetails provides information about the batch which has been validated. Refer section 11.1.5 for details.
156
Version 2.1
14.1.6 element DataQualityReport/AckSummary The element AckSummary provides details of the acknowledgement of the batch by FIU. Figure: Overview of AckSummary
157
Version 2.1
Table: Details of AckSummary Element XMLFileName BatchID UpoadTime ReportSize Description The name of the report file uploaded by the reporting entity. Unique acknowledgement number generated for the batch. The date and time of successful upload of the report. The size of the report in kilobytes. If the file is uploaded without a digital signature an upload confirrmation is required to be sent to FIU. ConfirmationRequired Permissible values are: Y - Yes N - No Number of reports uploaded by the reporting entity. Number of reports rejected after Preliminary validation Data quality rating communicated to the reporting entity after each successful upload and validation. Permissible values are: A - No fatal or non fatal errors B - Only non fatal errors C - <50% reports with fatal errors D - >= 50% reports with fatal errors X Not rated Refer section 14.1.6.1 for further details on enumeration. FatalErrorCount NonFatalErrorCount FatalPreliminaryCount NonFatalPreliminaryCount FatalAdvancedCount NonFatalAdvancedCount Remarks Number of fatal errors at the batch and report level. Number of non fatal errors at the batch and report level. Number of fatal errors after preliminary validation at the batch and report level. Number of non fatal errors after preliminary validation at the batch and report level. Number of fatal errors after advanced validation at the batch and report level. Number of non fatal errors after advanced validation at the batch and report level. Additional information about the data quality report. Section 14.1.7 Section 14.1.8 Section 14.1.9 Section 14.1.10 Section 14.1.11 Section 14.1.12 50 Yes Yes Yes Yes Yes Yes No 1 Yes Length 30 10 20 10 Mandatory Yes Yes Yes Yes
ReportUploadCount ReportRejectCount
10 10
Yes Yes
QualityRating
Yes
158
Version 2.1
No fatal or non fatal The batch of reports contains no fatal or non fatal errors errors Only non fatal errors The batch of reports has no fatal errors but only non fatal errors <50% reports with fatal errors >=50% reports with fatal errors Non rated Few reports (<50%) in the batch have been rejected due to fatal errors Large number of reports (>=50%) in the batch have been rejected due to fatal errors The batch has not been rated
14.1.7 element DataQualityReport/AckSummary/FatalErrorCount The element FatalErrorCount provides the count of fatal errors in the batch and report. Figure: Overview of FatalErrorCount
159
Version 2.1
Table: Details of FatalErrorCount Element TotalBatchCount TotalReportCount Description Total number of fatal errors in the batch level elements. Total number of fatal errors in the reports. Length 10 10 Mandatory Yes Yes
14.1.8 element DataQualityReport/AckSummary/NonFatalErrorCount The element NonFatalErrorCount provides the count of Non fatal errors in the batch and report. Figure: Overview of NonFatalErrorCount
160
Version 2.1
Table: Details of NonFatalErrorCount Element TotalBatchCount TotalReportCount Description Total number of non fatal errors in the batch level elements. Total number of non fatal errors in the reports. Length 10 10 Mandatory Yes Yes
14.1.9 element DataQualityReport/AckSummary/FatalPreliminaryCount The element FatalPreliminaryCount provides the count of fatal errors after the preliminary validation is done of the batch and report. Figure: Overview of FatalPreliminaryCount
161
Version 2.1
Table: Details of FatalPreliminaryCount Element TotalBatchCount TotalReportCount Description Total number of fatal errors in the batch level elements after preliminary validation Total number of fatal errors in the reports after preliminary validation Length 10 10 Mandatory Yes Yes
14.1.10 element DataQualityReport/AckSummary/NonFatalPreliminaryCount The element NonFatalPreliminaryCount provides the count of non fatal errors after the preliminary validation is done of the batch and report. Figure: Overview of NonFatalPreliminaryCount
162
Version 2.1
Table: Details of NonFatalPreliminaryCount Element TotalBatchCount Description Total number of non fatal errors in the batch level elements after preliminary validation Total number of non fatal errors in the reports after preliminary validation Length 10 Mandatory Yes
TotalReportCount
10
Yes
14.1.11 element DataQualityReport/AckSummary/FatalAdvancedCount The element FatalAdvancedCount provides the count of fatal errors after the advanced validation is done of the batch and report. Figure: Overview of FatalAdvancedCount
163
Version 2.1
Table: Details of FatalAdvancedCount Element TotalBatchCount TotalReportCount Description Total number of fatal errors in the batch level elements after advanced validation Total number of fatal errors in the reports after advanced validation Length 10 10 Mandatory Yes Yes
14.1.12 element DataQualityReport/AckSummary/NonFatalAdvancedCount The element NonFatalAdvancedCount provides the count of non fatal errors after the advanced validation is done of the batch and report. Figure: Overview of NonFatalAdvancedCount
164
Version 2.1
Table: Details of NonFatalAdvancedCount Element TotalBatchCount Description Total number of non fatal errors in the batch level elements after advanced validation Total number of non fatal errors in the reports after advanced validation Length 10 Mandatory Yes
TotalReportCount
10
Yes
14.1.13 element DataQualityReport/PreliminaryValidation The element PreliminaryValidation provides details of batch level and report level errors. Figure: Overview of PreliminaryValidation
Table: Details of PreliminaryValidation Element BatchLevelErrors Refer section 14.1.14 for details. Details of fatal and non fatal errors in the submitted reports. Refer section 14.1.15 for details. Description Details of fatal and non fatal errors at the batch level. Length Section 14.1.14 Mandatory Yes
ReportLevelErrors
Section 14.1.15
Yes
165
Version 2.1
14.1.14 element DataQualityReport/PreliminaryValidation/BatchLevelErrors The element BatchLevelErrors provides details of batch level errors. Figure: Overview of BatchLevelErrors
Table: Details of BatchLevelErrors Element Error Refer section 14.1.14.1 for details on type error. Description Details of error. Length Section 14.1.14.1 Mandatory Yes
166
Version 2.1
Table: Details of Error Element Description Type of Error. Permissible values are: F -Fatal Error N -Non Fatal Error P- Probable Error Refer section 14.1.14.2 for details on enumeration. Validation Rule Message XPath Validation rule which has resulted in error Message giving explanation of the error Path where the error has occurred 100 150 100 Yes Yes Yes Length Mandatory
ErrorType
Yes
14.1.14.2 Enumeration for ErrorType Code F Error Type Fatal Error Error Description Error Resolution
A batch containing fatal errors will be allowed to be Errors in XML file which uploaded but reports with fatal errors will be rejected. The would result in rejection of reporting entity would be required to resubmit revised report reports after resolving fatal errors Errors in XML file which No requirement to submit a revised report. These errors will not lead to rejection of are taken into account to compute data quality rating. The reports errors may be resolved in future submissions Errors in XML file which These are not confirmed errors. The reporting entity will not lead to rejection of would be required to verify and submit revised report only reports if error is confirmed
Probable Error
14.1.15 element DataQualityReport/PreliminaryValidation/ReportLevelErrors The element ReportLevelErrors provides details of report level errors.
167
Version 2.1
Table: Details of ReportLevelErrors Element ReportError Refer section 14.1.16 for details. Description Details of error in the report. Length Section 14.1.16 Mandatory Yes
14.1.16 element DataQualityReport/PreliminaryValidation/ReportLevelErrors/ReportError The element ReporlError provides details of report that is in error with the serial number of the report Figure: Overview of ReportError
Table: Details of ReportError Element ReportSerialNum Error Description Unique Serial number identifying the report Details of error in the report. Refer section 14.1.14.1 for details on Type Error Length 10 Section 14.1.14.1 Mandatory Yes Yes
14.1.17 element DataQualityReport/AdvancedValidation The element AdvancedValidation provides details of batch level and report level errors. Figure: Overview of AdvancedValidation
168
Version 2.1
14.1.18 element DataQualityReport/AdvancedValidation/BatchLevelErrors The element BatchLevelErrors provides details of batch level errors. Refer section 14.1.14 for BatchLevelErrors. 14.1.19 element DataQualityReport/AdvancedValidation/ReportLevelErrors The element ReportLevelErrors provides details of report level errors with the serial number of the report. Refer section 14.1.15 for ReportLevelErrors.
169
Version 2.1
170
Version 2.1
171
Version 2.1
S No. 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75
Code Country Name KH CM CA CV KY CF TD CL CN CX CC CO KM CG CD CK CR CI HR CU CY CZ DK DJ DM DO EC EG SV GQ ER EE ET FK FO FJ FI FR GF Cambodia Cameroon Canada Cape Verde Cayman Islands Central African Republic Chad Chile China Christmas Island Cocos (Keeling) Islands Colombia Comoros Congo Congo, The Democratic Republic Of The Cook Islands Costa Rica Cte D'ivoire Croatia Cuba Cyprus Czech Republic Denmark Djibouti Dominica Dominican Republic Ecuador Egypt El Salvador Equatorial Guinea Eritrea Estonia Ethiopia Falkland Islands (Malvinas) Faroe Islands Fiji Finland France French Guiana
172
Version 2.1
S No. 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114
Code Country Name PF TF GA GM GE DE GH GI GR GL GD GP GU GT GG GN GW GY HT HM VA HN HK HU IS IN ID IR IQ IE IM IL IT JM JP JE JO KZ KE French Polynesia French Southern Territories Gabon Gambia Georgia Germany Ghana Gibraltar Greece Greenland Grenada Guadeloupe Guam Guatemala Guernsey Guinea Guinea-Bissau Guyana Haiti Heard Island And McDonald Islands Vatican City State Honduras Hong Kong Hungary Iceland India Indonesia Iran, Islamic Republic Of Iraq Ireland Isle Of Man Israel Italy Jamaica Japan Jersey Jordan Kazakhstan Kenya
173
Version 2.1
S No. 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153
Code Country Name KI KP KR KW KG LA LV LB LS LR LY LI LT LU MO MK MG MW MY MV ML MT MH MQ MR MU YT MX FM MD MC MN ME MS MA MZ MM NA NR Kiribati Korea, Democratic People's Republic Of Korea, Republic Of Kuwait Kyrgyzstan Lao People's Democratic Republic Latvia Lebanon Lesotho Liberia Libyan Arab Jamahiriya Liechtenstein Lithuania Luxembourg Macao Macedonia, The Former Yugoslav Republic Of Madagascar Malawi Malaysia Maldives Mali Malta Marshall Islands Martinique Mauritania Mauritius Mayotte Mexico Micronesia, Federated States Of Moldova, Republic Of Monaco Mongolia Montenegro Montserrat Morocco Mozambique Myanmar Namibia Nauru
174
Version 2.1
S No. 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192
Code Country Name NP NL AN NC NZ NI NE NG NU NF MP NO OM PK PW PS PA PG PY PE PH PN PL PT PR QA RE RO RU RW BL SH KN LC MF PM VC WS SM Nepal Netherlands Netherlands Antilles New Caledonia New Zealand Nicaragua Niger Nigeria Niue Norfolk Island Northern Mariana Islands Norway Oman Pakistan Palau Palestinian Territory, Occupied Panama Papua New Guinea Paraguay Peru Philippines Pitcairn Poland Portugal Puerto Rico Qatar Reunion Island Romania Russian Federation Rwanda Saint Barthelemy Saint Helena, Ascension And Tristan da Cunha Saint Kitts And Nevis Saint Lucia Saint Martin Saint Pierre And Miquelon Saint Vincent And The Grenadines Samoa San Marino
175
Version 2.1
S No. 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231
Code Country Name ST SA SN RS SC SL SG SK SI SB SO ZA GS ES LK SD SR SJ SZ SE CH SY TW TJ TZ TH TL TG TK TO TT TN TR TM TC TV UG UA AE Sao Tome And Principe Saudi Arabia Senegal Serbia Seychelles Sierra Leone Singapore Slovakia Slovenia Solomon Islands Somalia South Africa South Georgia And The South Sandwich Islands Spain Sri Lanka Sudan Suriname Svalbard And Jan Mayen Islands Swaziland Sweden Switzerland Syrian Arab Republic Taiwan, Province Of China Tajikistan Tanzania, United Republic Of Thailand Timor-Leste Togo Tokelau Tonga Trinidad And Tobago Tunisia Turkey Turkmenistan Turks And Caicos Islands Tuvalu Uganda Ukraine United Arab Emirates
176
Version 2.1
S No. 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248
Code Country Name GB US UM UY UZ VU VE VN VG VI WF EH YE ZM ZW XX ZZ United Kingdom United States United States Minor Outlying Islands Uruguay Uzbekistan Vanuatu Venezuela, Bolivarian Republic Of Viet Nam Virgin Islands, British Virgin Islands, U.S. Wallis And Futuna Western Sahara Yemen Zambia Zimbabwe Not categorised Others
177
Version 2.1
178
Version 2.1
S No. 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75
Code CRC HRK CUP CZK DKK DJF DOP XCD EGP SVC ERN EEK ETB EUR FKP FJD GMD GEL GHS GIP XAU XFO GTQ GNF GYD HTG HNL HKD HUF ISK XDR INR IDR IRR IQD ILS JMD JPY JOD
Currency Name Costa Rican Colon Croatian Kuna Cuban Peso Czech Koruna Danish Kroner Djibouti Franc Dominican Peso East Caribbean Dollar Egyptian Pound El Salvador Colon Eritrean nakfa Estonian Kroon Ethiopian Birr EU Euro Falkland Islands Pound Fiji Dollar Gambian Dalasi Georgian Lari Ghanaian New Cedi Gibraltar Pound Gold (Ounce) Gold Franc Guatemalan Quetzal Guinean Franc Guyana Dollar Haitian Gourde Honduran Lempira Hong Kong SAR Dollar Hungarian Forint Icelandic Krona IMF Special Drawing Right Indian Rupee Indonesian Rupiah Iranian Rial Iraqi Dinar Israeli New Shekel Jamaican Dollar Japanese Yen Jordanian Dinar
179
Version 2.1
S No. 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114
Code KZT KES KWD KGS LAK LVL LBP LSL LRD LYD LTL MOP MKD MGA MWK MYR MVR MRO MUR MXN MDL MNT MAD MZN MMK NAD NPR ANG NZD NIO NGN KPW NOK OMR PKR XPD PAB PGK PYG
Currency Name Kazakhstani Tenge Kenyan Shilling Kuwaiti Dinar Kyrgyz Som Lao Kip Latvian Lats Lebanese Pound Lesotho Loti Liberian Dollar Libyan Dinar Lithuanian Lit as Macao Patacas Macedonian Denary Malagasy Ariary Malawi Kwacha Malaysian Ringgit Maldivian Rufiyaa Mauritanian Ouguiya Mauritius Rupee Mexican Peso Moldovan Leu Mongolian Tugrik Moroccan Dirham Mozambique New Metical Myanmar Kyat Namibian Dollar Nepalese Rupee Netherlands Antillean Guilder New Zealand Dollar Nicaraguan Cordoba Oro Nigerian Naira North Korean Won Norwegian Kroner Omani Rial Pakistani Rupee Palladium (Ounce) Panamanian Balboa Papua New Guinea Kina Paraguayan Guarani
180
Version 2.1
S No. 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153
Code PEN PHP XPT PLN QAR RON RUB RWF SHP WST STD SAR RSD SCR SLL XAG SGD SBD SOS ZAR KRW LKR SDG SRD SZL SEK CHF SYP TWD TJS TZS THB TOP TTD TND TRY TMT AED UGX
Currency Name Peruvian Nuevo Sol Philippine Peso Platinum (Ounce) Polish Zloty Qatari Rial Romanian New Leu Russian Ruble Rwandan Franc Saint Helena Pound Samoan tala Sao Tome And Principe Dobra Saudi Riyal Serbian Dinar Seychelles Rupee Sierra Leone Silver (Ounce) Singapore Dollar Solomon Islands Dollar Somali Shilling South African Rand South Korean Won Sri Lanka Rupee Sudanese Pound Suriname Dollar Swaziland Lilangeni Swedish Krona Swiss Franc Syrian Pound Taiwan New Dollar Tajik Somoni Tanzanian Shilling Thai Baht Tongan Pa'anga Trinidad And Tobago Dollar Tunisian Dinar Turkish Lira Turkmen New Man at UAE Dirham Uganda New Shilling
181
Version 2.1
S No. 154 155 156 157 158 159 160 161 162 163 164 165 166
Code XFU UAH UYU USD UZS VUV VEF VND YER ZMK ZWL XXX ZZZ
Currency Name UIC Franc Ukrainian Hryvnia Peso Uruguayo US Dollar Uzbekistani Sum Vanuatu Vatu Venezuelan Bolivar Fuertes Vietnamese Dong Yemeni Rial Zambian Kwacha Zimbabwe Dollar Not Categorised Others
182