User Manual Reports FINGate Portal
User Manual Reports FINGate Portal
0
Module Reports
Version 1.1
Year 2022
Restricted Page |1
User Manual - FINGate 2.0 - Reports Version 1.1
Table of Contents
1 Introduction ......................................................................................................................................... 5
1.1 Purpose ........................................................................................................................................ 5
1.2 Scope ............................................................................................................................................ 5
2 Report Preparation and Submission ..................................................................................................... 6
2.1 Overview of ‘Report dashboard navigation and actions’ .............................................................. 6
2.2 Batch and Report creation through Bulk Upload process ............................................................ 8
2.2.1 Bulk Data Upload ...................................................................................................................8
2.2.1.1 Fresh data ......................................................................................................................... 9
2.2.1.2 Incremental data ............................................................................................................ 10
2.2.2 Rectification of errors during bulk upload .......................................................................... 11
2.2.2.1 Error rectification directly through portal ...................................................................... 11
2.2.2.2 Error rectification in bulk file .......................................................................................... 13
2.2.3 Batch Creation from bulk uploaded source data ................................................................ 13
2.3 Batch and Report creation through Manual process.................................................................. 14
2.3.1 Report Preparation ............................................................................................................. 15
2.3.1.1 Cash transaction Report Type (CTR) for Banks ............................................................... 15
2.3.1.2 Counterfeit Currency Report (CCR) for Banks ................................................................ 17
2.3.1.3 Non-Profit Organisation Transaction Report (NTR) for Banks ........................................ 18
2.3.1.4 Cross Border Wire Transfer Reports (CBWTR) for Banks ................................................ 20
2.3.1.5 Suspicious Transaction Reports (STR) for Banks ............................................................. 21
2.3.1.6 Cash transaction Report Type (CTR) for Casino .............................................................. 24
2.3.1.7 Cross Border Wire Transfer Report (CBWTR) for Casino ................................................ 25
2.3.1.8 Suspicious Transaction Report (STR) for Casino ............................................................. 26
2.3.1.9 Cash Transaction Report Type (CTR) for FI/NBFC/Others ............................................... 26
2.3.1.10 Suspicious Transaction Report Type (STR) for FI/NBFC/Others .................................. 28
2.3.1.11 Suspicious Transaction Report Type (STR) for Payment Aggregators ......................... 30
2.3.1.12 Suspicious Transaction Report Type (STR) for Brokerage Firms ................................. 32
2.3.1.13 Suspicious Transaction Report Type (STR) for Exchange Houses................................ 33
2.3.1.14 Suspicious Transaction Report Type (STR) for Depositories ....................................... 35
2.3.1.15 Suspicious Transaction Report Type (STR) for MTSS .................................................. 37
2.3.1.16 Suspicious Transaction Report Type (STR) for Card System Operators ...................... 38
2.3.1.17 Property Transaction Report (PTR) ............................................................................. 39
2.3.2 Report creation .................................................................................................................. 40
2.4 Batch Submission Process .......................................................................................................... 42
1 Introduction
1.1 Purpose
Project FINnet 2.0 envisions to streamline and redefine the process of collection, processing, and
dissemination of data for the purpose of effectively generating meaningful intelligence to curb
money laundering activities and enforce the provision of PMLA in India. This is a project of national
importance and aims to strengthen the financial security architecture of India. The mission
statement of FINnet 2.0 states – To provide quality financial intelligence for safeguarding the
financial system from the abuses of money laundering, terrorism financing, and other economic
offenses.
FINnet 2.0 is implemented as a set of three (3) systems to ensure that the data ingested and
processed by the three is isolated and immune to security threats as much as possible and all data
is secure. The systems are listed below –
The proposed FINGate system shall consist of multiple reporting mechanisms to ensure compliance
and facilitate quick and easy reporting.
This document is the user manual for FINGate Portal – Reports module of the FINnet 2.0 System. To
access the FINGate portal, navigate to https://fingate.gov.in.
1.2 Scope
The scope of this document is to provide guidance on using the FINGate module and act as a user
manual. The functionalities covered in this user manual are submission of:
1. Principal Officers of RE
2. Designated Directors of RE
3. Non Principal Officer users of RE
The following functionalities are excluded in this version of the user manual and will be included
in subsequent versions of the user manual.
This sub-module deals with report preparation and submission by REs using FINGate 2.0 portal.
Reports can be prepared either by the principal officer or non-principal officer user. Only the principal
officer can submit the batches which consist of one or more reports. Users can create the reports in
bulk or individually.
All the reports submitted will have the following report sections:
a) KYC profile
i. The KYC section of the report is compulsory for all reports where the RE is filing a
report on its customers or non-customers.
ii. The KYC and Transaction formats have been combined for certain RE types including
MTSS, Card System Operators and all Property transactions.
iii. Along with a common KYC profile, there would also be account profile that would
capture details of different accounts held by the customer. This account profile would
differ based on the RE type. As an example, a banking account profile would be
different from an insurance policy account.
iv. The relationships between KYC / Simplified KYC with the accounts must be specified in
the Account Person Relation section
b) Transaction profile
i. The Transaction section of the report covers details of every transaction that the RE is
including as part of the concerned report.
ii. For each type of format, the RE has the flexibility to report one or many transactions.
iii. For each type of transaction, the format will be standardised. Such a format may differ
across RE types but will be the same within a RE type.
The user will access the reports module by clicking on ‘My Reports’ link on the left panel.
The user will view major tabs for report preparation and submission. This section will give an
overview to navigate through the ‘My Reports’ module of FINGate 2.0 system.
1. Bulk Data Upload: The user will be able to upload data to create bulk submission. Source data
for multiple reports and report types can be uploaded at once which can also be modified from
the below screen. Furthermore, the user can also upload the incremental data to the previously
uploaded data.
2. Batch Creation: The user will be able to create batch from the uploaded data. The user can view the
list of all the batches created till date irrespective of the batch status and can also filter the reports
by the respective batch ‘Status’.
Reports: The user will be able to view all the created reports. The user can do the modification to
an existing report and can also add more reports to an existing batch. The user will also be able to
filter the reports by their respective ‘Batch Number’, ‘Report Type’ and ‘Status’. Furthermore, the
user can delete the reports in the draft status.
3. Create New Report: In this tab, the user will input certain reference fields to initiate batch
creation for the following report types:
• Reports to be submitted periodically
1. Cash Transaction Report (CTR)
2. Cross Border Wire Transfer Report (CBWTR)
3. Property Transaction Report (PTR)
4. Non-Profit Organization Transaction Report (NTR)
5. Counterfeit Currency Transaction Report (CCR)
A batch is referred to as a group of reports submitted by a RE PO. A batch can only contain one
type of report. For instance, a batch can only have one or more CTRs or STRs, but a batch cannot
contain both a CTR and STR. Each record within a batch will be referred to as a report, which will
be a combination of the KYC section, transaction(s), and GoS (in case of STR only).
1. The user will navigate to ‘Bulk Data Upload’ tab as shown in the below screenshot.
3. The user will be directed to the ‘Bulk Data Upload’ page from where the option to browse and
select the applicable .zip file for bulk upload can be accessed.
4. Allowed file format is CSV. The files are to be uploaded as a .zip file.
5. The zip file should not have any sub folders, the upload will fail in this case.
6. The different report types will have applicable sample .zip files. The .zip file will contain all the
report type specific relevant KYC, transaction and GOS format files.
Please refer to Annexure (Section 3.1) to view the template of the .csv file.
7. The user can update only the applicable format files and can choose to remove the irrelevant
format files from the .zip folder to be uploaded.
8. Please note that the names of the csv files should not be changed.
9. The user can load data as fresh or incremental data. The details are listed below.
The user can choose to upload fresh data. This will ensure that all previously loaded files are overwritten,
and data in the current file will be considered for creation of batches and reports.
The user can upload incremental data. Using this option, the user will be able to incrementally add more
data to the previously uploaded data. If the user has distributed all the report data into multiple zip files,
then the first zip file should be uploaded with option as ‘Fresh data’ and subsequent files should be
uploaded with option as ‘Incremental Data’. After all the files have been uploaded, errors corrected,
batches created and submitted the cycle for the current period is completed.
In the next cycle or for additional reports to be created, the process mentioned above must be repeated.
After uploading source data, the user will be able to view all the errors in the uploaded file.
1. The user can also modify the errors directly though the portal.
2. The user can click on the error count to see the error details in the respective record.
3. The user can hover over ‘error’ to know the error details and then click the ‘edit’ icon to modify the
record.
1. After uploading bulk source data and correcting all the identified errors, the user can proceed with
batch creation.
2. Users should take care to correct all errors before batch creation, else the system will ignore records
with errors for the batch creation and proceed with the rest of the records.
3. It should be noted that FIU will conduct advanced data validations after batch submission. RE should
not assume that the errors detected in the portal are the complete list of data validations. It is possible
that reports may get rejected subsequently by FIU after report submission.
4. The user shall click on the ‘Batch creation’ tab.
5. The user will be navigated to the ‘New batch’ screen where the user can select the report type as the
uploaded data.
6. The user is required to select the relevant reporting month. In the case of PTR, user should select the
reporting quarter. In the case of STR, user should select the reporting date.
7. The user shall also mention the Batch reference number which can be of ‘alphanumeric’ type. This
number is an internal reference number of the RE and FIU will not do any validations on this number.
1. The user can create reports manually by using web form in the portal.
2. The user shall navigate to the ‘Create new report’ tab. The user will be directed to ‘New report’
screen.
3. The user can choose from six report types that are listed below. Please note that only the report
types applicable for the RE type will be listed.
a) Cash Transaction Report (CTR)
b) Property Transaction Report (PTR)
c) Counterfeit Currency Transaction Report (CCR)
d) Non-Profit Organisation Transaction Report (NTR)
e) Cross Border Wire Transfer Report (CBWTR)
f) Suspicious Transaction Report (STR)
4. The user shall mention report reference number, batch reference number as well as reporting
period is to be selected from the drop down. The report reference and batch reference number
are alphanumeric and are internal reference numbers of RE. FIU will not perform any validations
on this.
1. The user will land on the below page on selecting the report type.
2. The user can see previously entered details such as reporting period, batch, and report reference
number.
3. This information will be common for every report type.
4. The detailed process of report creation for every report type is explained in the next sections.
1. The user will see the following tabs for Cash transaction Report type:
a) Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals or legal entities
iii. Account Details – to be filled with account details. If the transactions pertain to a customer,
please ensure that the account details are entered and saved before entering the
transaction details.
iv. Account Person Relation – the KYC details for individual / non-individual for customers
and simplified KYC for non-customers need to be linked to the account.
b) Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
1. The user will see the following tabs for Counterfeit currency Report type:
a) Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation– the KYC details for individual / non-individual for customers and
simplified KYC for non-customers need to be linked to the account.
b) Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c) Transaction detail
i. Counterfeit currency deposited
2. User can fill multiple KYC details in one CCR, KYC is not mandatory. However, if KYC is available, then
the RE must provide it. After filling the details, click on ‘Save’. Mandatory fields need to be filled to save
the records.
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one CCR. After filling the details, click on ‘Save’. Mandatory fields
need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction from the list
view as shown below.
1. The user will see the following tabs for NTR Report type:
a) Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation – the KYC details for individual / non-individual for customers
and simplified KYC for non-customers need to be linked to the account.
b) Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c) Transaction detail
i. NEFT/RTGS Transaction
ii. IMPS transaction
iii. UPI Transaction
iv. Cash transaction at ATM
v. Cash transaction at branch
vi. General transaction format
2. User can fill multiple KYC details in one NTR, minimum one KYC is mandatory. After filling the details,
click on ‘Save’. Mandatory fields need to be filled to save the records.
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one NTR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction from the
list view as shown below.
1. The user will see the following tabs for Cross Border Wire Transfer Report:
a) Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation– the KYC details for individual / non-individual for customers
and simplified KYC for non-customers need to be linked to the account.
b) Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c) Transaction detail
i. Cross border wire transfer beyond specified threshold
2. User can fill multiple KYC details in one CBWTR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records.
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one CBWTR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction from the
view as shown below.
1. The user will see the following tabs for Suspicious Transaction Report:
a. Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation– the KYC details for individual / non-individual for
customers and simplified KYC for non-customers need to be linked to the
account.
b. Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c. Transaction detail
i. Cash ATM – for cash transactions conducted at an ATM/CDM
ii. Cash Branch – for cash transactions conducted at a branch
iii. NEFT – for transactions conducted via NEFT/RTGS
iv. IMPS – for transactions conducted via IMPS
v. Bank UPI – for transactions conducted via UPI
vi. General Reporting – for general reporting of transactions.
d. Ground of Suspicion
2. User can fill multiple KYC details in one STR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records.
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one STR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction details.
6. The following sections, as described below, constitute the GOS profile –
a. First part shows the KYC summary. These details will be auto populated from the KYC /
simplified KYC details entered and is non-editable. User should select at least one record
as ‘Primary Entity’.
b. Second part shows the transaction summary. These details will be auto populated and
non-editable
c. Third part shows the account summary of all reported accounts. Transaction summaries
for 12 months preceding the first reported transaction need to be entered by the RE user
for each account.
d. User must enter the details of Fund Flow – Source and Destination of Funds in the next
section
e. User will be required to add tags to the report depending on suspicions, in the next section
f. In the following section, user will then have to respond to queries that would be system
generated based on the tags selected above.
g. User may add attachments as shown below. Maximum size of each attachment is 5MB.
Multiple attachments can be uploaded up to 5 attachments. Allowed file types are pdf,
doc, docx, jpg, png, xls, xlsx and zip.
1. The user will see the following tabs for Cash transaction Report type:
a) Non-Customer
b) Transaction detail
2. User can fill multiple KYC details in one CTR, minimum one KYC is mandatory. After filling the details,
click on ‘Save’. Mandatory fields need to be filled to save the records.
3. There can be multiple transactions in one CTR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
4. The user can select and fill relevant non-customer KYC and transaction from the list view as shown
below.
1. The user will see the following tabs for Cross Border Wire Transfer Report:
a) Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
b) Transaction detail
i. Casino CBWTR Format
2. User can fill multiple KYC details in one CBWTR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records.
3. There can be multiple transactions in one CBWTR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
4. The user can select and fill relevant KYC (for customer and non-customer) and transaction from the
list view as shown below.
1. The user will see the following tabs for Suspicious Transaction Report:
a. Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals or legal entities
b. Transaction detail
i. Casino STR format
c. Ground of Suspicion
2. User can fill multiple KYC details in one STR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records.
3. There can be multiple transactions in one STR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
4. The user can select and fill relevant KYC (for customer and non-customer) and transaction from
the list view as shown below.
5. GOS profile must be entered as detailed in section 2.3.1.5, point 6 of this document.
1. The user will see the following tabs for Cash Transaction Report type:
a) Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation – the KYC details for individual / non-individual for customers and
simplified KYC details for non-customers need to be linked to the account.
b) Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c) Transaction detail
i. Cash at Branch
2. User can fill multiple KYC details in one CTR, minimum one KYC is mandatory. After filling the details,
click on ‘Save’. Mandatory fields need to be filled to save the records.
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one CTR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction from the
list view as shown below.
1. The user will see the following tabs for Suspicious Transaction Report:
a. Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation – the KYC details for individual / non-individual for
customers and simplified KYC details for non-customers need to be linked to the
account.
b. Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c. Transaction detail
i. NBFC STR Format
d. Ground of Suspicion
2. User can fill multiple KYC details in one STR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records. Every STR must have
one GOS record
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one STR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction details.
6. GOS profile must be entered as detailed in section 2.3.1.5, point 6 of this document.
1. The user will see the following tabs for Suspicious Transaction Report:
a. Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation – the KYC details for individual / non-individual for
customers and simplified KYC details for non-customers need to be linked to the
account.
b. Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c. Transaction detail
i. Bank UPI – for reporting UPI payments
ii. Wallet – for reporting wallet payments
iii. General Reporting – for general transaction reporting
d. Ground of Suspicion
2. User can fill multiple KYC details in one STR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records. Every STR must
have one GOS record
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one STR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction
details.
6. GOS profile must be entered as detailed in section 2.3.1.5, point 6 of this document.
1. The user will see the following tabs for Suspicious Transaction Report:
a. Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation – the KYC details for individual / non-individual for
customers and simplified KYC details for non-customers need to be linked to the
account.
b. Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c. Transaction detail
i. Brokerage STR Format
d. Ground of Suspicion
2. User can fill multiple KYC details in one STR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records. Every STR must have
one GOS record.
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one STR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction details.
6. GOS profile must be entered as detailed in section 2.3.1.5, point 6 of this document.
1. The user will see the following tabs for Suspicious Transaction Report:
a. Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation – the KYC details for individual / non-individual for
customers and simplified KYC details for non-customers need to be linked to the
account.
b. Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c. Transaction detail
i. Exchange Houses STR Format
d. Ground of Suspicion
2. User can fill multiple KYC details in one STR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records. Every STR must
have one GOS record
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one STR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction
details.
6. GOS profile must be entered as detailed in section 2.3.1.5, point 6 of this document.
1. The user will see the following tabs for Suspicious Transaction Report:
a. Customer
i. Individual KYC – to be filled for Individual persons
ii. Non-Individual KYC – to be filled for non-individuals
iii. Account Details – to be filled with account details
iv. Account Person Relation – the KYC details for individual / non-individual for
customers and simplified KYC details for non-customers need to be linked to the
account.
b. Non-Customer
i. Simplified KYC Individual - to be filled for Individual persons
ii. Simplified KYC Non-Individual - to be filled for non-individuals
c. Transaction detail
i. Depositories STR Format
d. Ground of Suspicion
2. User can fill multiple KYC details in one STR, minimum one KYC is mandatory. After filling the
details, click on ‘Save’. Mandatory fields need to be filled to save the records. Every STR must
have one GOS record
3. Account detail is mandatory in case of customer.
4. There can be multiple transactions in one STR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records.
5. The user can select and fill relevant KYC (for customer and non-customer) and transaction
details.
6. GOS profile must be entered as detailed in section 2.3.1.5, point 6 of this document.
1. The user will see the following tabs for Suspicious Transaction Report:
a. Transaction detail
i. Combined KYC and Transaction Profile
b. Ground of Suspicion
2. User can fill multiple Transaction details in one STR, minimum one Transaction is mandatory.
After filling the details, click on ‘Save’. Mandatory fields need to be filled to save the records.
Every STR must have one GOS record
3. GOS profile must be entered as detailed in section 2.3.1.5, point 6 of this document.
2.3.1.16 Suspicious Transaction Report Type (STR) for Card System Operators
1. The user will see the following tabs for Suspicious Transaction Report:
a. Transaction detail
i. Card System Operators STR Format
b. Ground of Suspicion
2. There can be multiple transactions in one STR. After filling the details, click on ‘Save’. Mandatory
fields need to be filled to save the records. Every STR must have one GOS record.
3. GOS profile must be entered as detailed in section 2.3.1.5, point 6 of this document.
1. The user will see the following tabs for Property transaction Report type:
a) Combined KYC and Transaction detail
2. User can fill multiple transactions in one PTR. After filling the details, click on ‘Save’. Mandatory fields
need to be filled to save the records.
3. The user can select and fill relevant transactions from the view as shown below.
1. Once the user fills all the relevant details in the form, the user can click on save.
2. The user will be able to preview the filled details.
3. The user can click on ‘Back to list’ to view the summary.
4. The user can add more KYC/transaction type.
5. The user can finally navigate to the ‘reports’ tab to view the created report.
1. For submitting any draft batch, the user can click on the view icon.
2. The user will be able to view all the reports inside the batch.
3. The user can click on the ‘Submit’ button.
4. The user will be required to upload DSC.
5. Post successful upload of DSC the user can view the status of the batch as submitted.
6. Unique Batch ID and unique Report ID shall be generated by the system for each batch and each
report being submitted.
1. The user can add more reports to an existing batch by navigating to the ‘Reports’ tab and clicking
on ‘New Report’.
2. In the next page, select the report type, enter the RE report reference number, same RE batch
reference number in which new reports is to be added, reporting period and click on ‘Save & Next’.
3. The KYC and transaction details can be entered and saved. The new report will get added to the
existing batch.
7. The user can view the batch again in the list view, the status of the batch now will be “recalled”.
8. Batches with “recalled” status will only be in Read only mode.
3 Annexures
The name of the file is KC1 and should not be changed. This file is used to capture data of Customer KYC
for Individuals.
PAN PAN of the individual No 4th Alphabet (AAAAA) will be "P" for individuals
Sample: 91-9562013300
Mobile number of 10 Digit Numeric (If country = India)
Mobile Number No
the individual
The name of the file is KC2 and should not be changed. This file is used to capture data of Customer KYC
for Non-Individuals or entities.
The name of the file is KCS1 and should not be changed. This file is used to capture data of simplified KYC
for individuals who are not customers of the RE.
The name of the file is KCS2 and should not be changed. This file is used to capture data of simplified KYC
for non-individuals who are not customers of the RE.
The name of the file is Account_Detail and should not be changed. This file is used to capture data of
account.
The name of the file is Account_Person_Relation and should not be changed. This file is used to capture
the relations between the accounts and persons in the report.
The name of the file is TC1 and should not be changed. This file is used to capture the details of cash
transactions conducted through ATM.
The name of the file is TC2 and should not be changed. This file is used to capture the details of cash
transactions conducted through branch.
The name of the file is TC3 and should not be changed. This file is used to capture the details of cash
transactions conducted through casinos.
Transaction Date Date of the transaction Yes Note: While using Excel to edit csv,
please ensure that the date format is
saved as DD/MM/YYYY
Acceptable format HH:MM:SS
Transaction Time Time of the transaction No Note: While using Excel to edit csv,
please ensure that the time format is
saved as HH:MM:SS
Amount of the
Amount Yes
transaction
If Entity Type = Individual
Name of the reported
Name Yes 1. Special Characters are not allowed.
entity
2. Numbers are not allowed.
Acceptable format DD/MM/YYYY
1. Date of birth cannot be less than 01-
01-1900.
2. Date of birth cannot be greater than
Current Date.
DoB of the reported
Date of Birth Yes 3. Date of birth cannot be greater than
entity
date of reported transaction.
The name of the file is TS1 and should not be changed. This transaction profile will be filled in the
scenario the RE wishes to report a NEFT/RTGS payment
Transaction Date Date of the transaction Yes Note: While using Excel to edit
csv, please ensure that the date
format is saved as
DD/MM/YYYY
Acceptable format HH:MM:SS
The name of the file is TS2 and should not be changed. This transaction profile will be filled in the
scenario the RE wishes to report an IMPS payment.
Transaction Date Date of the transaction Yes Note: While using Excel to edit csv,
please ensure that the date format
is saved as DD/MM/YYYY
Acceptable format HH:MM:SS
Transaction Time Time of the transaction No Note: While using Excel to edit csv,
please ensure that the time format
is saved as HH:MM:SS
Name of the entity
Sender Name sending the reported No Min length 3, Max length 100
funds
The name of the file is TS and should not be changed. This transaction profile will be filled in the scenario
the RE wishes to report an UPI payment.
Sample: 91-9562013300
This format will be used in scenarios where the above-mentioned reporting formats do not apply.
Transaction Time Time of the transaction No Note: While using Excel to edit csv,
please ensure that the time format is
saved as HH:MM:SS
Amount of the transaction
Amount INR Yes
in Indian Rupee
Amount of the transaction
Amount FC No Min length:1, Max length:20
in FC (if applicable)
Use the Currency ID downloaded
FC Code FC Code (if applicable) No from the metadata for country from
‘Learning and Resources’
FIU will accept reports without
Account number of the
account number up to a threshold. If
Account Number entity sending the No
this threshold is exceeded, then
reported funds
subsequent reports will get rejected
Branch Code of
Branch Code of Account No
Account
Purpose of
Purpose of Transaction No Min length:1, Max length:100
Transaction
Name of the entity sending Min length:3, Max length:100
the reported funds If Entity Type = Individual
Option to declare Not 1. Special Characters are not allowed.
Available 2. Numbers are not allowed.
Sender Name No
Either Sender Name or the FIU will accept reports without
declaration that it is not sender name up to a threshold. If this
available needs to be threshold is exceeded, then
provided. subsequent reports will get rejected
Either Sender Name or the
Declaration (If
declaration that it is not Yes, if Sender Name Valid values are NA. If this is not
Sender name is
available needs to be is not available required leave this field as blank.
not available)
provided.
10 Digit Numeric (If country = India)
Free length, Numeric (If country !=
India)
Mobile number of the
Sender Mobile 1. All 10 digits cannot be the same
sender of the reported No
Number 2. "1234567890" not allowed
funds
FIU will accept reports without
mobile number up to a threshold. If
this threshold is exceeded, then
subsequent reports will get rejected
IFSC Code/ branch ID of
Min length:3, Max length:30
the sender of the reported
Option to declare Not Available
Sender funds
FIU will accept reports without this
IFSC/Branch Either Sender IFSC/Branch No
field up to a threshold. If this
ID/MICR ID/MICR or the declaration
threshold is exceeded, then
that it is not available
subsequent reports will get rejected
needs to be provided.
The name of the file is CB1 and should not be changed. This transaction profile will be filled in the
scenario a bank wishes to report a cross-border wire transfer.
The name of the file is CC1 and should not be changed. This file is used to capture the details of counterfeit
transaction.
The name of the file is Counterfeit_Detail and should not be changed. This file is used to capture the details
of counterfeit instruments involved in the transaction.
3.1.17 CB2- Cross Border Wire Transaction for Casino - Bulk Template
This transaction format is to be used by card system operators to report suspicious transactions.
Non Indian
Pin code as part of the PIN code (Metadata is applicable if Country
Beneficiary No
address = India)
Pincode
Non Indian Pay- Pin code as part of the PIN code (Metadata is applicable if Country
No
Out Pincode address = India)
Non Indian
Payee Agent Pin code as part of the PIN code (Metadata is applicable if Country
No
Pincode address = India)
Free Text
Sender State Sender State Name as part No If the country is not India, use this field for
Name of sender address. Sender Address. If the country is India,
leave this field as blank.
Free Text
Sender District Sender District Name as No If the country is not India, use this field for
Name part of sender address. Sender Address. If the country is India,
leave this field as blank.
Free Text
Sender City /
Sender City Name as part of No If the country is not India, use this field for
Village / Town
sender address. Sender Address. If the country is India,
Name leave this field as blank.
The name of the file is PTR and should not be changed. This file is used to capture the details of property
transactions.
Transaction Date Date of the transaction Yes Note: While using Excel to edit csv,
please ensure that the date format is
saved as DD/MM/YYYY
Transaction
Amount of the transaction Yes
Amount
Transaction
Yes Free text with length 5 -255
Address 1
Transaction
Transaction Address Line 1 Yes Free text with length 5 -255
Address Locality
Use the Country ID downloaded from
Transaction Country as part of registered
Yes the metadata for country from
Address Country address
‘Learning and Resources’
Transaction
Pin code as part of registered PIN code (Metadata is applicable if
Address Pin Yes
address Country = India)
Code
If the Seller
Declaration (If PAN is not
If the Seller PAN of the individual is
seller PAN is not available,
not available, this becomes
available) enter NA.
mandatory
Else leave it
blank.
PAN exemption Number of the Mandatory if "Not Available" is
Seller PEKRN No
seller declared in the PAN field
Acceptable values are Individual/
Seller Entity
Entity Type of the seller Yes Company/ Firm/ HUF/ Government
Type
Office/ Others
Seller Address 1 Yes Free text with length 5 -255
Seller Address
Seller Address Line 1 Yes Free text with length 5 -255
Locality
Use the Country ID downloaded from
Seller Address
Country as part of Seller Address Yes the metadata for country from
Country
‘Learning and Resources’
Seller Address PIN code (Metadata is applicable if
Pin code as part of Seller Address Yes
Pin Code Country = India)
Use the State ID downloaded from the
Seller Address
State as part of Seller Address Yes metadata for state from ‘Learning and
State
Resources’
Use the District ID downloaded from
the metadata for district from
Seller Address
District as part Seller Address Yes ‘Learning and Resources’
District
Note – The district id in combination
with the state id will be unique
Use the City ID downloaded from the
Seller Address
City as part of Seller Address Yes metadata for city from ‘Learning and
City
Resources’
If Entity Type = Individual
Name of the entity purchasing the
Buyer Name Yes 1. Special Characters are not allowed.
property
2. Numbers are not allowed.