Axis Bank Ltd

Jocata GRID ™
Business Requirements Document
Draft B
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

Contacts

Communications regarding this document should be directed to:

Santosh Myadam, Product Manager Prashant Muddu, Managing Director

Jocata Financial Advisory & Technology Jocata Financial Advisory & Technology Private
Private Limited Limited
8-2-351/w/3/B, 2nd Floor, 8-2-351/w/3/B, 2nd Floor,
Road No 3, Banjara Hills Road No 3, Banjara Hills
Hyderabad, 500034 Hyderabad, 500034

Telephone: +91 98661 82078 Telephone: +91 80081 12360

Email: santosh.myadam@jocata.com Email: prashant.muddu@jocata.com

2|Page
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

DOCUMENT CHANGE LOG

Document Name Jocata GRID – Business Requirements Document for Axis Bank Ltd.
Change Log
Version Date Log Author
nd
Draft A 2 May 2016 Draft BRD based on discussions with Axis Bank users Jocata
Draft B 5th May 2016 Updated draft BRD based on discussion post the review of Jocata
Draft A

APPROVALS

Sl. Approver Name Designation Date Remarks

1
2
3
4
5

CONFIDENTIAL INFORMATION

This document is confidential to Jocata Financial Advisory & Technology Services Pvt. Ltd. (“Jocata”). The
document contains information and data that Jocata considers confidential and proprietary (“Confidential
Information”).
Any disclosure of Confidential Information or use of it by any other party will be damaging to Jocata. Ownership
of all Confidential Information, no matter in what media it resides, remains with Jocata. Confidential
Information in this document shall not be disclosed without express written permission by Jocata and shall not
be duplicated, used, or disclosed – in whole or in part.

3|Page
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

Table of Contents

1 INTRODUCTION .................................................................................................................................................. 5

1.1 PURPOSE ...................................................................................................................................................... 5

1.2 SCOPE .......................................................................................................................................................... 5

1.2.1 Out-of-scope ................................................................................................................................................. 5

1.3 ASSUMPTIONS ............................................................................................................................................... 5

1.4 CONSTRAINTS ................................................................................................................................................ 5

1.5 REFERENCES .................................................................................................................................................. 5

1.6 OUTSTANDING POINTS .................................................................................................................................... 5

2 BUSINESS REQUIREMENTS ................................................................................................................................. 7

2.1 RISK RATING ................................................................................................................................................. 7

2.1.1 Current Process ............................................................................................................................................. 7
2.1.2 Future Process ............................................................................................................................................... 7

2.2 TRANSACTION MONITORING RULES .................................................................................................................... 8

2.3 CASE CREATION.............................................................................................................................................. 8

2.3.1 Current Process ............................................................................................................................................. 8
2.3.2 Future Process ............................................................................................................................................... 8

2.4 CASE ASSIGNMENT ......................................................................................................................................... 9

2.4.1 Current Process ............................................................................................................................................. 9
2.4.2 Future Process ............................................................................................................................................... 9

2.5 CASE WORKFLOW..........................................................................................................................................10

2.5.1 Current Process ........................................................................................................................................... 10
2.5.2 Future Process ............................................................................................................................................. 11

2.6 REGULATORY REPORTS ...................................................................................................................................16

2.6.1 Current Process ........................................................................................................................................... 16
2.6.2 Future Process ............................................................................................................................................. 17

2.7 REPORTS .....................................................................................................................................................18

2.7.1 Future Process ............................................................................................................................................. 18

2.8 ADMINISTRATION ..........................................................................................................................................18

2.8.1 Future Process ............................................................................................................................................. 18

3 TECHNOLOGY REQUIREMENTS [TBD] ................................................................................................................19

3.1.1 Current Process ........................................................................................................................................... 19

3.1.2 Future Process ............................................................................................................................................. 19

4|Page
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

1 INTRODUCTION
Axis Bank Ltd. has selected Jocata Financial Advisory and Technology Services Pvt. Ltd. to implement a
comprehensive solution for addressing AML requirements. Following are the 2 products that are offered to
Axis Bank as part of Jocata GRID:

Suspicious Transaction Analysis and Reporting (Jocata STAR™) is a comprehensive monitoring solution for
customer and account transactions across business lines and products, which helps financial institutions detect
and analyze potentially suspicious activity. The application provides a robust alert and case management
platform for proactive investigation and reporting of suspicious activities.
Central Tracking and Reporting Application (Jocata CENTRA™) is the reporting module of STAR that enables
generation, correction and re-generation of the regulatory reports like Cash Transaction Reports, Suspicious
Transaction / Activity Reports etc.

1.1 Purpose
The purpose of this document is to provide the complete information of all the business requirements
captured during the scope discussions conducted with Axis Bank users from various departments.

1.2 Scope
Following is the scope of this document
1. List all functional requirements for risk categorization of customers, rules required for AML
monitoring, case assignment, case workflow and generation of regulatory reports
2. List all non-functional requirements including interfacing details, user management details and
infrastructure details

1.2.1 Out-of-scope
Following items are not part of this document’s scope
1. Process of extracting data from source systems
2. Uploading of regulatory reports to FINNET portal

1.3 Assumptions
Sl. Assumption Ref # Requirement
TBD

1.4 Constraints
TBD

1.5 References
TBD

1.6 Outstanding Points

Sl. Action Point Responsibility Expected By Status
1. List of standard narrations to close an alert
Axis
needs to be provided by the bank. The

5|Page
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

‘Standard Narrations’ must be non-editable. A

second editable box should be present in case
the user would want to update any additional
comments.
2. Format of the STR details page that is Axis
internally used for approval process
3. List of rules, parameters and brief summary of Axis
logic
Fields required for filing CBWT report to be
4. provided by the bank to Jocata to perform a Axis
feasibility test. The report would contain all
the fields required to file the report
Additional fields required by the bank for
CCR’s to be provided by the bank [Central
Office reporting to RBI]. Jocata to perform a
5. feasibility test to analyse the work-effort in Axis
developing the additional fields. These
additional fields are required from a MIS
report perspective.
Risk parameters to be finalized and provided
6. to Jocata for better understanding of the Risk Axis
Model incorporated by the bank
7. Document to be provided to the bank on ETL Jocata
process and data transformation
Table/File structure recommended by Jocata
8. to be provided to bank to better understand Jocata
the data migration process and to foresee and
potential issues
9. Jocata to provide all the data points required Jocata
to perform ‘link Analysis’ functionality in STAR
The bank has requested for the hardware
10. requirement and an estimate on the time Jocata
required for processing Alerts that are to be
generated on a ‘Rolling Period’ frequency

6|Page
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

2 Business Requirements

2.1 Risk Rating

Risk rating is the process of assigning a risk profile (low or medium or high) to a customer using static and
transactional information of the customer.

2.1.1 Current Process

1. Risk is calculated as a two-step process
a. Static Risk
i. Static Risk is calculated using following parameters at customer level. Bank is also
planning to add few additional parameters in the near future
1. Customer Type
2. Occupation
3. Country
ii. If any of the parameters is high for a customer, then the customer is considered as high
b. Dynamic Risk (Transaction based) is calculated at account level using following logic
i. Dynamic risk a quarterly activity using a combination of manual and automated
processes
ii. Every quarter, bank calculates a matrix using a combination of Account Vintage
(Account Age), Customer Type and Product Code
iii. For every unique combination of above three parameters, system calculates the
following values
1. Average Account Turnover [Sum of all credits and debits in all accounts of the
group / no. of accounts in the group]
2. Average Cash Turnover [Sum of all cash credits and cash debits in all accounts
in the group / no. of accounts in the group]
iv. Each account is then compared against the average values calculated for corresponding
group
v. If account’s value is [condition], then Dynamic Risk for account is marked as low or
medium or high
2. Account Risk is then determined as the highest of the Static Risk (at customer level) and Dynamic Risk
of the account
3. Highest of the accounts’ risk is considered for customer
4. Customer risk cannot be downgraded, either by the system or manually by the user.

2.1.2 Future Process

BR # Requirement Description
1. Risk should be calculated using combination of Static Risk and
Dynamic Risk as described above
2. End-to-end process should be automated / part of the system
without any user input
Account Risk Calculation 3. As part of dynamic risk calculation, system should only allow
upward movement of risk [e.g. if an account is medium risk
as part of previous calculation, and if it system determines
account as low risk in current calculation, then the system
should retain the account at medium risk]
7|Page
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

4. Highest of the accounts’ risk should be considered as

customer risk
5. Customer risk should be considered for all purposes in the
Customer Risk
system. E.g. alert generation, regulatory reporting etc.
6. System should store risk both at an account level as well as at
customer level for display purposes
7. Report is required to show the details of changes to customer
Risk changes tracking
risk as an audit trail
8. Report 1: All changes to risk ratings of all customers in a given
period
Account risk report
9. Report 2: All changes to risk rating of a customer in a given
period

2.2 Transaction Monitoring Rules

TBD

2.3 Case Creation

Case creation is the process of creating and updating of cases based on the alerts generated in the system
using the rules defined.

2.3.1 Current Process

1. Incremental data from source systems is uploaded into existing AML system
2. Current AML system generates alerts based the rules defined
3. Standalone alerts are generated i.e. currently there is no system defined aggregation of alerts into a
case. However, the user interface provides an option to view all alerts of a customer at one place
4. Investigation process is primarily driven at an alert level i.e. individual suspected incident

2.3.2 Future Process

BR # Requirement Description
1. System should generate the alerts using the rules defined in
the system
Alert Generation
2. System should allow aggregation of alerts either at an account
level or at a customer level
3. All alerts that belong to a customer are auto-clubbed by the
system to create a case
4. Every case will have a unique Case ID
Case Creation 5. Investigation process is at an a case level i.e. common
investigation flow for all alerts associated with the case
6. Case details page provides the list of alerts associated with the
case
7. Any new alerts generated for a customer will get appended to
an existing case, if the customer has an open case in L1 or L2
Case Update level
8. If the case has already been moved to L3 or above tray then a
new case has to be created for any new alert generated for
8|Page
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

that customer
9. If customer doesn’t have any open case, then a new case has
to be created

2.4 Case Assignment

Case assignment is process of allocating cases to various users present in the system. This objective is to
ensure that the workload is evenly distributed and that all users get to work all kinds of cases with respect
to type of rules involved, type of customer, risk of customer etc.

2.4.1 Current Process

1. All alerts generated in the system are extracted into a spread sheet
2. Using a pre-defined process, alerts are then allocated to different users by marking the User Name
against each of the alerts generated for the day
3. As the current investigation process is at an alert level (i.e. individual exception generated by a rule
and not consolidated case level), the assignment process is also at an alert level. However, alerts
that belong to a customer in a day are always assigned to the same user for the day
4. After allocating the alerts, the spread sheet is then circulated to all users for initiating the
investigation process

2.4.2 Future Process

BR # Requirement Description
1. System should allow case assignment to various users using
following parameters
i. Customer Type
ii. Branch
iii. Rule Name
2. User should be assigned only with the cases that match the
Case Assignment user’s assignment criteria
3. If all users are assigned with ‘all’ criteria, then all users can
see all cases
4. ‘Round robin’ based case allocation is required to distribute
cases evenly amongst various users
5. All system generated cases are to be assigned to L1 users by
default
6. System should allow mapping of users from L1 to L2
7. All cases forwarded by L1 user should directly go to the
mapped L2 user
L1 to L2 & L2 to L3 Mapping
8. All cases forwarded by L2 should go to L3 user
9. If there are more than one L3 users, then the cases should go
to all the L3 users
10. Case creation date is the date on which first alert generated
for the case
TAT calculation for 11. TAT for L1 users
investigation of cases i. TAT for L1 users should be calculated from the date
on which the case was assigned to the user
ii. In almost all cases, case creation date and case

9|Page
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

assignment date will be same. However, there can be

exception cases where case may not be assigned to
the user on the same day
12. TAT for L2 users
i. TAT for L2 users should be calculated as X days from
the case creation date, irrespective of the number of
days that a L1 user has taken to look into the case
13. TAT duration will remain same for a case irrespective of type
of alerts associated with the case (daily alert, weekly alert,
fortnightly alert or monthly alert)
14. Cases pending for more than X days must be notified to L3
users as a report.
15. Holiday master should be considered for TAT calculation
16. System should provide an option to enter the days on which
Leave / Vacation Marking a user is going to be on vacation / leave
17. System should not assign cases to users on those days

2.5 Case Workflow

Case Workflow is the end to end process involved in investigating suspicious cases generated in the system.

2.5.1 Current Process

1. L1, L2 and L3 are three investigation levels present in the system
2. L1 Initiates investigation work for the alerts that are assigned to the user using the spread sheet shared
with them every day for the alerts generated for that day
a. Retrieve all alerts for the customer using Customer ID (present in spread sheet)
b. Post analysis, L1 user will either close alert, mark it as false positive or forward to L2 user
c. If marked as false positive, then a maker checker approval is required
3. L2 receives alerts forwarded by L1 users as well as those re-assigned by L3 users
a. L2 users will either close alert, re-assign to any L1 user, mark it as false positive or forward to L3
user
b. If marked as false positive, then a maker checker approval is required
c. If an alert requires STR to be generated, then the L2 user will raise a request in OAS system by
providing all information related to STR
i. There are 3 levels of approvals in OAS system
ii. Post receiving approval in OAS, L2 user will fill in (copy & paste) STR details again into
current AML system and forward it to L3 users
iii. Case can be moved between L2 and L3 user for corrections and additions
d. L2 users will do a random checking of X% of the cases closed by L1 users
4. L3 receives alerts forwarded by L2 users
a. L3 users will either close alert, re-assign to any L2 or L1 user or mark it as false positive
b. If marked as false positive, then a maker checker approval is required
c. If an alert requires STR to be generated, then the L3 user will provide approval in OAS system
i. L3 will also review the STR details filled in AML system by L2 users
ii. L3 user will submit the STR details
iii. Post submission by L3 user, STR details are converted into XML files to be uploaded to
FIU [this function is outsourced to a different team]

10 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

5. Following is the information that the users typically use to investigate an alert
a. Customer profile – by navigating to Finacle
i. Date of birth
ii. Occupation / industry
iii. Risk rating
iv. Product code
b. Customer transaction summary – by navigating to Finacle
i. Cumulative turnover (CR and DR) since inception
ii. Value and volume of cash transactions in FY
iii. Value and volume of transfer transactions in FY
iv. Value and volume of clearing transactions in FY
v. Base branch vs. inter-sol cash deposits
c. Customer documents – by navigating to document management system
i. Account opening form
1. Address proof
2. ID proof
3. PAN
4. Other documents
ii. Account statement – by navigating to Finacle (CHRMAN)
iii. Details of previous STRs of the customer, if any – using spread sheet used for alert
assignment. A separate tab is maintained in this spread sheet that contains the list of
all recent STRs generated

2.5.2 Future Process

BR # Requirement Description
1. Six levels of investigation workflow is required as follows:
a. Branch Level [Branch User]
b. L1 Investigation [Analyst]
Case Workflow Process c. L2 Investigation [Reviewer]
d. L3 Investigation [Approver]
e. STR Reviewer [STR Reviewer]
f. STR Approver [STR Approver]
2. A simplified screen to be provided to branches for following
purposes
a. Raise a new subjective alert
b. Response to queries raised by L1 users
c. Fill CCR details
3. Branch users should be able to add the required information
Process flow for Branch Level
requested by L1 users and move the case back to L1 users
4. A pre-defined reminder period should be available so that a
notification goes to branch user to inform that a case is due
on that day
5. Email notifications must be provided to the branch users
once a case has been assigned to them by L1,
Process flow for L1 6. L1 users will get following cases:
Investigation a. Cases assigned by system

11 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

b. Cases re-assigned from by L2 users to L1 users

c. Cases for which branch has provided their comments
7. L1 users will be able to view all the case background details
as explained in section below ‘Case Background Details’
8. L1 users will be able to include comments, links to external
sites, any electronic document, tags to a case. Full details are
provided in section below ‘Case Tools’
9. Post investigation, L1 users can take one of the following
options
a. Re-assign to Branch Users
b. Close Case
c. Forward Case [Option to fill False Positive details]
10. L1 users should also be able to see cases that were previously
worked upon by them
11. L2 users will get following cases:
a. Cases forwarded by L1 users
b. Cases re-assigned from by L3 users to L2 users
c. Cases re-assigned from L4 or L5 users to L2 users
[related to STR]
12. L2 users will be able to view all the case background details
as explained in section below ‘Case Background Details’
13. L2 users will be able to include comments, links to external
sites, any electronic document, tags to a case. Full details are
provided in section below ‘Case Tools’
14. Post investigation, L2 users can take one of the following
Process flow for L2
options
Investigation
a. Re-Assign Case
b. Close Case
c. Mark Case as False Positive [for cases that are
already recommended as false positive by L1 users]
d. Forward Case
i. Option to fill STR details
ii. Option to fill False Positive details
15. L2 users should also be able to see cases that were previously
worked upon by them
16. L2 users should also be able to see all cases present at L1
users mapped to them
17. L3 users will get following cases:
a. Cases forwarded by L2 users
b. Cases re-assigned from L4 or L5 users to L3 users
Process flow for L3 [related to STR]
Investigation c. Cases created as a result of ‘subjective alert’ raised
by branches or other teams
18. L2 users will be able to view all the case background details
as explained in section below ‘Case Background Details’

12 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

19. L2 users will be able to include comments, links to external

sites, any electronic document, tags to a case. Full details are
provided in section below ‘Case Tools’
20. Post investigation, L3 users can take one of the following
options
a. Re-Assign Case
i. Re-Assign to L1
ii. Re-Assign to L2 [With option to update STR
details] [Format to be shared by Axis Bank]
b. Close Case
c. Mark Case as False Positive [only for cases that are
already recommended as false positive by L2 users]
d. Forward Case [With option to update STR details]
21. L3 users should also be able to see cases that were previously
worked upon by them
22. L3 users should also be able to see all cases present at all L2
and L1 users
23. STR Reviewer users will get following cases:
a. Cases assigned forwarded by L3 users
b. Cases re-assigned from L5 to L3 users
24. STR Reviewer users will be able to view all the case
background details as explained in section below ‘Case
Background Details’
25. STR Reviewer users will be able to include comments, links to
external sites, any electronic document, tags to a case. Full
details are provided in section below ‘Case Tools’
26. Post investigation, STR Reviewer users can take one of the
Process flow for STR Reviewer
following options
[STR Reviewer]
a. Re-Assign to L2 [With option to update STR details]
b. Re-Assign to L3 [With option to update STR details]
c. Forward Case
27. STR Reviewer users should also be able to see cases that
were previously worked upon by them
28. For leave management, option should be available in the
system to assign ‘STR Approver’ permissions to ‘STR
Reviewer’
29. STR Reviewer users should also be able to see all cases
present at all L3, L2 and L1 users
30. STR Approver users will get following cases:
a. Cases assigned forwarded by STR Reviewer users
31. STR Approver users will be able to view all the case
Process flow for STR Approver
background details as explained in section below ‘Case
[STR Approver]
Background Details’
32. STR Approver users will be able to include comments, links to
external sites, any electronic document, tags to a case. Full

13 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

details are provided in section below ‘Case Tools’

33. Post investigation, STR Approver users can take one of the
following options
a. Re-Assign to L2 [With option to update STR details]
b. Re-Assign to L3 [With option to update STR details]
c. Re-Assign to STR Reviewer
d. Approve STR
e. Close Case
34. STR Approver users should also be able to see cases that
were previously worked upon by them
35. STR Approver users should also be able to see all cases
present at all STR Reviewer, L3, L2 and L1 users
36. A mobile app is also required for STR Review and STR
Approver users
37. App should provide the list of cases pending for their
approval with high level summary of the STR background and
grounds of suspicion
38. App users should be able to perform the actions they are
eligible to
a. STR Reviewer
i. Re-assign [L2 or L3]
Mobile App for STR Reviewer ii. Forward
and STR Approver users b. STR Approver
i. Re-assign [L2 or L3 or STR Reviewer]
ii. Approve STR
iii. Close Case
39. App is required both on Android and IOS platforms
40. In order to facilitate this requirement, the bank has
suggested an alternate arrangement by installing a ‘Juniper’
box on the cloud. This process would temporarily provide a
VPN access to the banks STR information for the L4 and L5
users to provide the necessary approvals.
41. System should have a upper limit for accepting false positives
a. Maximum Duration
b. Maximum Amount
c. Maximum Frequency
False Positives
42. Option to further increase the values of a false positive
should be available as a separate permission. Maker checker
is not required here as the false positive is already created by
some other user
43. User should have the ability to ‘Whitelist’ a customer along
Whitelisting of customers
with maker-checker functionality.
44. All subjective alerts raised by branch or any other users
Workflow for subjective alerts should first be assigned to L3 users
45. L3 users will review and If required, assign it to any L2 user

14 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

46. Subjective alerts should not be clubbed with any other open
case of the customer that may be present in the system at
that point of time
47. X% of cases investigated by L1 users are randomly checked by
L2 users
48. Cases to be picked in random order by the system
Criteria for selecting cases for 49. L2 users should have the option to pick any other cases of L1
L2 review users for review
50. Option to add comments both by L2 and L1 users as part of
random sample check should be available
51. L2 users should be able to re-open the case if required
52. Customer Details including profile of customer, risk rating,
address details, contact details etc. as captured from
respective source systems should be made available to the
user
53. Account Details including account number, product code,
account open date, account balance, account maturity date,
account closed date and account status
Case Background Details
54. Transaction Details of the current alert as well as other
transactions in a given period should be displayed
55. Transaction Summary [Format to be shared by Axis]
56. Customer Profile Summary and Customer Peer Group
Summary
57. Network analysis of the customer in graphical view and
summary of network
58. Comments facility to be available. User should be able to add
any number of comments
a. Each comment should be stored along with the
details of the user who has added and timestamp
b. Users should be able to delete the comments added
by themselves but not by other users
59. Option to attach electronic documents as evidences to cases
should be available
Case Tools a. Attachment size should be 5 mb per attachment
60. Option to include hyperlinks to external sites should be
available
61. Option to add tags to case should be available
62. A ‘Work in progress’ button should be present for all users to
indicate that the review process on a case has started by
him/her. A ‘filter’ option must also be present to assist the
users to view only the cases that they have marked as ‘Work
in Progress’ should be available
63. The various work-flow actions that can be undertaken by a
Others user post the investigation process must be displayed as
buttons.

15 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

64. ‘Close’ option should be displayed first

65. The user should have the ability to search or filter on
‘Account Number’
66. Pre-populated comments in the form of templates that can
be further updated by users
67. Customer Name updated at account level sometimes doesn’t
flow to Customer level. As the regulatory reports use
Customer Name at Customer Level, there should be a way of
updating customer names directly in Jocata STAR [either
front end or back end] – This is an exception case that
requires further discussion

2.6 Regulatory Reports

2.6.1 Current Process

2.6.1.1 CTR Filing Process

1. The transaction details for the month are consolidated by the banks IT team. The required .xml is
provided to the AML team to file to FIU-IND
2. CTRs for non-customers are also included into the customer CTR XML and a consolidated file is
generated
3. Due to the ‘file limit’ constraints in the FIU-IND website, the xml file is split by the IT team into smaller
files for easier upload.

2.6.1.2 NTR Filing Process

1. The NTR customers to be part of the NTR reports are consolidated by the IT team for the generation of
the xml file. The AML team subsequently uploads the details onto the FIU-IND website.

2.6.1.3 STR Filing Process

i. The STR process flow begins at the L2 level who identifies a potential STR.
ii. Subsequent approvals are provided by L3, L4 and L5 on OAS (Online Approval system). Once L5
provides the approval it is assigned to the originator i.e. L2
iii. L2 updates all the approved STR information from OAS to FCDMS and assigns it to an ‘Outsourced
Employee’ (OS)
iv. The OS then creates the STR .xml file and submits it to FIU-IND for final STR submission.

2.6.1.4 CCR Filing Process

TBD

2.6.1.5 CBWT Filing Process

1. CBWT report includes transactions of both Axis customers and non-customers
2. Transactions that qualify for CBWT reporting from various departments are consolidated into a
common table
3. CBWT report is generated from this common table
4. Most of the fields required for filing CBWT for non-customers is not available and hence default values
specified by FIU are used

16 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

2.6.2 Future Process

BR # Requirement Description
1. CTR Report generation should be completely provided from
the front end
2. User should be able to download the report in XML format
from end
3. CTR Report needs to be filed on a customer level and not at
CTR Filing
an account level
4. Option to regenerate CTR in case of any additional details
received from source system should be available
5. Feasibility to include non-customer transactions into CTR to
be analysed
6. NTR Report generation should be completely provided from
the front end
7. User should be able to download the report in XML format
NTR Filing
from end
8. Option to regenerate NTR in case of any additional details
received from source system should be available
9. CBWT should be generated from a separate table into which
various departments in bank will provide records to be
considered for CBWT
10. CBWT Report generation should be completely provided from
CBWT Filing the front end
11. User should be able to download the report in XML format
from end
12. Option to regenerate NTR in case of any additional details
received from source system should be available
13. Access to be provided to branch users for filing CCRs should
be available
14. The branch user should be warned if a CCR is being reported
to update the CCR data beyond the mentioned time-frame.
15. Option to generate Monthly CCRs should by consolidating all
the CCRs raised by branches should be available.
16. System should include all CCR incidents where following
CCR Filing
conditions are met:
i. Date of detection is less than 1st of current month
[CCR Reporting Month]
ii. Date of report is greater than or equal to 1st of
previous month [CCR Reporting Month]
17. User should be able to download the report in XML format
from end
18. All relevant information to be pre-populated before the user
can create the STR file
STR Filing
19. User should be able to view all the STRs approver by ‘STR
Approver’ users

17 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

20. User should be able to convert the above STRs into XML files
21. Option to regenerate STR in case of any additional details
received from source system should be available
22. Option to flag the alert which has resulted in creating the STR
should be available
23. Option to flag the account which has resulted in creating the
STR should be available
24. Option to exclude accounts and / or transactions before
reporting to FIU should be available
25. Option to include additional accounts and / or transactions
into STR should be available
26. Option to view number of CTRs, STRs, CCRs, CBWTs and NTRs
reported on a customer should be available
Others
27. Feasibility to provide an external utility to split regulatory
files to be analysed

2.7 Reports
2.7.1 Future Process
1. User rights report - Details the current role and permissions
assigned to a particular user
2. Scenario Threshold Report – Thresholds assigned to the alerts
MIS Reports must be displayed in this report
3. Report on alerts referred to Branch’s – Alerts which have
been assigned by L1 users requesting information from
branch’s must be displayed in this report

2.8 Administration
2.8.1 Future Process
1. This functionality should be present for the below process’s
i. False Positive
Maker- Checker functionality ii. Risk Editor
iii. Scenario Editor
2. User Management

18 | P a g e
Jocata GRID ™ Business Requirements Document Axis Bank Ltd.

3 Technology Requirements [TBD]

3.1.1 Current Process

3.1.1.1 Current Infrastructure

Sl. No.
Application Server 1
1 RAM 32 GB
2 Core 8 core
3 OS Windows
4 App Server Websphere
Database Server 1
5 RAM 120 GB
6 Core 48
7 OS Linux
8 DB Oracle 11g

3.1.1.2 Current Volumes

Total Incremental
No. of Customers 4,50,00,000 30,000 per Day
No. of Accounts 8,00,00,000 60,000 per Day
No. of Transactions 30,00,000 per Day; Peak volume 1,50,00,000 per Day
No. of CTRs per Month 80,000 per Month; 600 MB

3.1.1.3 Current EOD Process

1. Data from the requires source systems is extracted and moved to staging tables
2. Common staging tables are used for all the source systems
3. Post completion of data movement into staging stables, the EOD process of AML system is initiated
4. Customer, account and name screening jobs are auto initiated by the current system
5. Transaction job and alerts job are manually run by Axis IT support team
6. EOD in AML system is started on the subsequent day and the alerts are made available to the users on
T + 2 basis at minimum

3.1.2 Future Process

TBD

19 | P a g e