Annexure C (Technical Compliance Sheet)

Please specify S/C in the table below to indicate how the solution meets the Banks
requirement.
All the below requirements are mandatory. The bidder has to specify complied by marking
S (Standard). If any of the technical specification is not complied by the bidder then it
should be customized without any extra cost. Such point shall be marked as C
(Customized).
S. No
Technical Specification
Comply(S/C)
1
The system should be three tier (Web/App/DB) web based and should
Available
able to support simultaneous use of the system by multiple users.
2
The proposed solution should be able to increase or decrease processing
Available
resources as per business needs, without the necessity of re-writing
code, or undertaking other major efforts.
3
The Proposed Solution should be able to store data as per Banks
Available
retention policy. During this period, Data recall should not require any
additional coding or additional retrieval procedure. The archival and
retrieval programs should facilitate easier analysis of old data.
4
The system should be able to archive transactional database records.
Available
Archived data should always be available in the system. The user at all
points of time should be able to access and print archived data.
5
System should support archiving of data that are beyond a specified
Available
time horizon. This should be parameterizable.
6
Export of data to secondary storage device should be supported by the
Available
system.
7
The system should be able to provide intuitive and current online
Available
documentation.
8
The system should have flat file import/export functionality to export
Available
transaction data and static data in the following formats and as per the
regulatory requirements: Microsoft Excel Format (.XLS/.XLSX) Microsoft
Word Format (.DOC/.DOCX) Comma separated values (.CSV)
Text file (.TXT), PDF, XML etc
9
The proposed solution should allow users to be controlled (creation,
Available
activation, deactivation, deletion etc.) by a specific administrator.
10
Addition of features should be allowed only through a properly revised
Available
upgrade and data migration method.
11
The system should enable profiling of users and definition of control
Available
levels & passwords.
12
The system should enable creation of different access groups with
Available
different access control. Users may belong to multiple groups.
13
Log on to the system should require users to provide unique user
Available
identity and form of personal identification e.g. a password.
14
Banks Password management features like length and pattern, password
Available
encryption, expiry, disabling after unsuccessful attempts, time-out,
force password change for events etc.
15
System Administration should provide for creation, deletion and
Available
modification of users, upgrade users and assigning data
access/modification rights of various user groups.

16
17
18

19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

Access only to designated users, and user set- up should be centrally

controlled through a specific administration module.
Maker Checker concept for all type of transactions.
Generation of detailed audit trails with following features:
List of all users logged on to the system
List of attempted unauthorized logins
Details of databases accessed and modified by the users.
Generation of daily audit trails. Separate audit trail for exceptional
transactions.
L
Provide adequate backup and recovery features.
Database locking features in the situation that there are multiple
accesses and updates on the same record.
Unified online view for each transaction record.
Data extraction/fetching from other databases should be done using
relevant ETL tools like Oracle Integrator or SQL Server Integration
Services etc.
Mapping of transaction records to support transaction, account,
customer and household dimensions
Support for multiple data types (nonmonetary event data, geographic
data, risk lists, third-party data, associate data and a variety of
customer information data) in addition to transaction data
Data model for efficient data upload from Core Banking Solution and
other applications of Bank like HRMS MIS, Data warehouse etc.
SMS and Email Alerts as per the regulatory requirements
The application must have Open Web Application Security Project
(OWASP) compliance
Integration with existing and future versions of Core Banking Solution
The solution should work successfully on all reputed web Browsers with
their current and future versions
There should not be any loop hole/vulnerability in the product, which
can leads to any kind of attack.
All the modules of the software should be fully integrated and no
manual intervention should be needed for inter-modules operations.
Capable to support processing on real time, online, off-line, batch
mode, etc. should also support scheduling and defining of jobs.
Should support centralized, distributed as well as hybrid databases.
Support encryption & hashing of data during exchange internally and
with external systems.
Passwords must be kept encrypted in the database and should not be
visible using any source.
Access to the system for all the users should be available only through
menu selection of the user interface.
Well defined purging policy mechanism to do from front end.
Should have the ability to capture non-financial events such as change

Available
Available

Available
Available
Customization
Available
Available
Available
Customization
Available
Available
Customization
Available
Available
Available
Available
Customization
Customization
Available
Available
Available
Available

39
40

of address etc.
Should offer facility for load balancing w.r.t. application server and
database server. Data replication functionality across databases.
Support automatic switchover to alternate/standby/failover server.

Available
Available

Annexure C1 (Functional Compliance Sheet)

Please specify S/C in the table below to indicate how the solution meets the
Banks requirement. All the below requirements are mandatory. The bidder has to
specify complied by marking S (Standard). If any of the technical specification is
not complied by the bidder then it should be customized without any extra cost.
Such point shall be marked as C (Customized).

1
1.1

1.2

1.3
1.4
1.5
1.6
1.7

1.8

General Requirements

Comply
(S/C)
The licenses for the proposed solution should Available
be enterprise unlimited licenses. There should
be no restriction on the license in terms of no.
of users, no. of transactions, no. of channels,
no. of Banking products, no. of branches and
asset size of bank.
Capable to view circular fund transfer between
Available
customers and linked entities. This information
should be viewable in graphical and tabular
format.
Capable to see the customer turnover details for the
past years along with the date of a/c opening and
closure as per banks requirement.
Generation of STR alerts, for details refer point 2.1 of
Section III
Capable of generating alerts on all the scenarios
prescribed by IBA/RBI/FIU-India and other regulatory
bodies, for details refer point 2.2 of Section III
Capable of generating any future scenarios prescribed
by IBA/RBI/FIU-India and other regulatory bodies from
time to time.
Capable of reporting of alerts by branches of the Bank
on the offline scenarios provided by IBA/RBI/FIU-India
and other regulatory bodies, based on events
happening in the Branch or across the counter, for
details refer point 2.3 of Section III
Capable of verification of existing customers, the new
customers (to be added in future) and walk in
customers against various negative lists prescribed by
the Regulatory Authorities (UN, OFAC etc.) For details
refer point 2.5 of Section III

Available
Available
Customization
Available
Available

Available

1.9
1.10

1.11
1.12
1.13
1.14
1.15

1.16
1.17
1.18

1.19
1.20
1.21
1.22
1.23
1.24
1.25
1.26

Capable of capturing scenario under Trade based money

laundering, for details refer point 2.4 of Section III
Capable of uploading custom lists into the application
electronically and checking the names of customers
with the data base of negative list to be acquired from
the service provider viz. Factiva, Worldcheck, Bankers
Aquity, Dow Jones,
Capable of providing online PAN verification of the
customers from NSDL site on real time basis while on
boarding as well as validating the existing customers.
Capable of adding/deleting a scenario as per Banks
requirement.
Capable of changing limits/thresholds/values as per
Banks requirement.
Capable of sorting of daily STR alerts on different
parameters like scenario, turnover, Region, Branch,
Geographical area etc.
Capable of having proper mechanism for distribution of
alerts to different users/screening officer at AML
Division and to different locations viz.
ZO/RO/Branches.
Capable of having Hierarchy for escalation of alerts to
different levels as per Banks requirement.
Capable of providing STR case in the required file
format of FIU-IND for uploading in their site.
Capable of providing details like Bio data of the
customer in a single screen, transactions in the
account/s for two years, to the Principal Officer (PO) to
enable the PO to help in drawing a conclusion of the
suspicion of the transaction.
Capable of providing details of progress of the work of
screening/scrutiny by the PO and the alerts under
correspondence with the Branches.
Capable of providing the position of alert scrutiny in
the form of Dash Board as per banks requirement.
Capable of maintaining proper record of the generated
STR alerts and after scrutiny closer and the STRs filed.
Capable of generating alerts on all the scenarios for
washing of Fund as per banks requirement.
Capable of having audit trail for all the activities by all
the users.
Capable of Generating CTR (cash Transactions Report)
as per prescribed format of FIU India.
Capable of Generating NTR (Non-Profit originations
Transactions Report) as per prescribed format of FIU
India.
Capable of Generating CCR (Counterfeit Currency

Available
Customization

Customization
Available
Available
Available
Available

Available
Customization
Available

Customization
Customization
Customization
Customization
Available
Customization
Customization
Customization

1.27
1.28
1.29
1.30
1.31
1.32
1.33
1.34

1.35

1.36

1.37

1.38

1.39
1.40
1.41

Report) as per prescribed format of FIU India.

Branch/Currency chest should be able to feed the CCR
details online at their end and KYC-AML division should
generate them for final submission.
Capable of Generating CBWTR (Cross Border Wire
Transfer Report) as per prescribed format of FIU India.
Capable of highlighting the cases on which STR is
already filed and viewable to the Central office users.
Capable to display Region Wise/Zone Wise no. of STR
generated in graphical and tabular forms.
Capable of highlighting the CTR submitted Accounts
along with their frequency of CTR transactions.
Capable to display Region Wise/Zone Wise no. of CCR
generated in graphical and tabular forms.
Capable of highlighting the CBWTR reported Accounts
along with their frequency of transactions.
Capable to display Country wise along with Zone/RO
wise No. of CBWTR reported Accounts.
Access to Branch users to view CTR accounts of their
respective branch.
Enables the analysts to scan the historical data and
retrace hidden patterns in the account profiles.
Analysts can preview the complete incident details
along with all other investigation tools and move such
incidents into their investigation dash boards.
AML officer to perform what if analysis and assess
the number of alerts that would result based on
specified thresholds. Capable of enabling alert flood
control by facilitating visualization of more practical
threshold values.
Capable to Support for SWIFT messages MT (543, 767,
195, 710, 203, 202COV, 102,
192,720,300,799,299,110,700,540,103,999,199,707,721
,
542320,541,202,499,196,742,111,410,400,701,760,450.
) as per requirement.
Option to enter specific keywords to screen against
SWIFT Transactions which can be configured for all
messages or specific SWIFT Message. Option to exclude
words for screening matches in SWIFT.
Capable to generate reports in multiple formats PDF,
RTF, HTML, XML and XLS. User can configure the
columns and print settings - header, footer etc.
User capable to schedule the report generation specify the frequency / timings.
User Capable to build his own reports for transactions,

Customization
Customization
Customization
Customization
Customization
Customization
Customization
Available

Customization

Customization

Available

Available

Available
Available
Available

1.42

1.43
1.44
1.45

1.46
1.47
1.48
1.49
1.50

1.51

1.52

1.53

customer and account by selecting from the parameters

in the report.
Access to Branch users to view KYC Non-complaint
accounts and certifying the geniuses of transactions in
their constituent accounts online as required by KYCAML division. Alerts should be thrown to BMs ID in
case of non-compliance.
The solution should have capability but not limited to
allow the supervisor to recheck the closed alerts of
users on random basis.
Capable to select multiple alerts for a single customer
or multiple customers for a specific case action by user
through a single button click
Capable to assign alerts based on Rules: a. Alert
assignment to users based on amounts b. Assignment of
branch/region specific alerts to specific users. c. Bulk
assignment/ Reassign of alerts.
The transaction data should have the capability to do
neural analysis i.e. predict possible money laundering
behavior in the future.
System should be able to trace links between
customers in the bank. The system should also have the
facility to record and save established relationships.
Should offer multi currency support.
Should be possible to generate list of accounts at a
given address.
System should support wire transfer surveillance with
the following features: Identify wire transfers
originating in correspondent or agent banks, identify
suspicious activity based on patterns of multiple wire
transfers, automatically generate reports on blocked
and rejected items, monitor internal/external and
domestic/international wire transfers.
System should have a alert scoring mechanism with
product having a relative score for each alert, the alert
scores be modified through the applications of rules,
provide for the categorization of alerts into groups for
similar suspicious activity and provide the user to drill
down into the details of the transactions on which the
alert was generated.
Bank should be able to create watch list of customers &
non-customers. Batch upload of customized list should
be possible. There should be a provision to assign risk
to the watch list. Changes to this watch list should also
be tracked, with complete audit trail.
Bank should be able to reduce false positives by
creating a white list in which user can add customers

Available

Available
Customization
Available

Customization
Customization
Available
Available
Customization

Customization

Available

Available

1.54
1.52

1.55
1.56

1.57
1.58
1.59
1.60
1.61
1.62
1.63

1.64
1.65
1.66

1.67

who have matched with list but are not deemed

suspicious. Should also have the ability to make a
fuzzy logic match with the list.
Should compare the additions to OSFI, OFAC or other
negative
Bank should be able to create watch list of customers &
non-customers. Batch upload of customized list should
be possible. There should be a provision to assign risk
to the watch list. Changes to this watch list should also
be tracked, with complete audit trail.
Any missing mandatory fields for an account holder
should be detected & reported.
The system should have provision to define benchmarks
for alert scenarios based on customer type, nature of
business, branch, and country & account risk. Should
include structured transactions, wire transfers, analysis
of unstructured text instructions contained in wire
transfers, patterns in multiple wire transfers, etc., high
risk geographies, high risk entities, transactions with no
apparent business purpose, funds transfer, transactions
that may indicate fraud rings, money market funds,
lines of credit, credit cards, installment loans, etc.
System should be capable of handling real time alerts.
Identify multiple wire transfers transactions with
common suspicious characteristics.
Automatically generate alerts/reports on blocked and
rejected items.
It should be possible to re-run any rule at any time and
as-of any past date.
Should be possible to manually change priority or risk
score of a suspicious transactions or event.
Should be possible to either assign a risk score or
change the status of a suspicious transactions or event.
Should have facility to store alerts, emails and all
necessary information recorded by the surveillance
officer to substantiate the case. This includes provision
to scan documents and attach them to specific cases.
Application should track key milestone dates in a case
(e.g. date open, date closed)?
The system should have complete audit trail of the
alerts generated.
System should generate MIS reports such as most active
accounts based on parameters such as deposit
frequency, withdrawal frequency, and transaction
frequency.
System should have a special interface for auditors and
IT users

Customization
Available

Available
Customization

Available
Available
Available
Available
Available
Available
Available

Available
Available
Available

Available

1.68

1.69
1.70
1.71
1.72
1.73
1.74
1.75
1.76
2
2.1

2.2
2.3

3
3.1
3.2
3.3

Use of link analysis is desirable which is a more

effective way to discover money-laundering activities
(Link analysis uses mathematical algorithms to find
common denominators and patterns in massive amounts
of data across the organization).
The user should have the facility of filtering alerts
based on parameters such as time, customer,
instrument, product and alert type.
Should be possible to do an age-wise analysis and view
alerts at a summary level, like no. of days open, etc.
Should be possible to generate MIS reports such as
suspicious transactions as a percentage of total
transactions, etc.
The solution should have automated case processing.

Available

The solution should be capable of providing a free form

text comments box on working case screens.
The solution should be able to differentiate between
cases which were created from alerts versus those
which were created manually.
The solution should have the ability to delete or
remove workflows if they become redundant as per
banks requirement.
The solution should have ability to integrate 3rd party
data/system as per banks requirement.
Risk Categorization

Available

Capable of Reviewing Risk categorization of the entire

customers every six months through a system based on
certain parameters set by the Bank as prescribed by
the Regulatory Authorities. The parameters are
dynamic and Administrator should be able to change
the same as per requirement of Regulator.
Capable of having mechanism for exercising Enhanced
Due Diligence in case of High Risk Customers and also
generating Audit trail.
If any account is to be compulsorily categorized in a
particular risk like high risk, the system must have the
capability to override the normal parameterization and
categories the account in high risk.
Unique Customer Identification Code

Available

Capable of identifying multiple CIFs of a single

customer on parameters like Date of Birth, PAN
Number, Aadhar Card,
Capable of grouping of the data of multiple CIFs into
Branch wise and Region wise for de-duplication
Capable of keeping track record of de-duplication

Available

Available
Customization
Available
Available

Available
Available
Available
Available

Available
Available

Available

Available
Available

process/progress.
4

Customer Profile Updation / KYC Compliance

4.1

Capable of generating reports of Branch wise Cust IDs

Available
due for KYC updation as per periodicity prescribed by
RBI i.e. 2 years for High risk, 8 years for Medium risk
and 10 years for Low risk customers and capable of
generating customized letter for each eligible
customer.
Capable of providing different reports regarding the
Available
deficiencies in KYC details/documents which will be
helpful in customer profile updation
Capable to generate & send letter as per bank template Customization
format to branches through email.

4.2
4.3

Available