Solution Review Document

Version 1.6
Date: 24/11/2021

Silicon Valley | Dubai | Lahore | London | Singapore | Sydney

Table of Contents
1. Client Summary..........................................................................................................................................3
2. Ticket Description.......................................................................................................................................4
3. Scope of Work (Internal)...........................................................................................................................6
4. Functional Requirements...........................................................................................................................7
5. Non-Functional Requirements..................................................................................................................8
6. Solution Details...........................................................................................................................................8
6.1 Proposed Solution........................................................................................................................................8
C-Holder Web / Mobile.......................................................................................................................................8
6.2 Alternate Solution(s) (Optional)................................................................................................................34
6.3 Impact Analysis.........................................................................................................................................34
6.4 Design Notes (Optional)............................................................................................................................35
6.5 Client Reference(s) Requesting Similar Solution (Optional)....................................................................35
7. Acceptance Criteria..................................................................................................................................36
8. Impacted Technology Areas....................................................................................................................36
9. Solution Category.....................................................................................................................................37
10. Billing Details..........................................................................................................................................37
11. Change Evaluation Checklist................................................................................................................37
11.1 Can the New functionality be used by all clients?...................................................................................37
11.2 Is 3rd Party/Network Integration Required?............................................................................................37
11.3 Is a CSD Update Required?.....................................................................................................................37
11.4 Is User Manual/Guide update Required?.................................................................................................38
12. Release Notification................................................................................................................................38
13. Approvals.................................................................................................................................................38
13.1 SRB Notes/Instructions............................................................................................................................38
14. Reference Documents.............................................................................................................................39

2
1. Client Summary

Client Name* Financial Institution Target Region* Card Network* Client Status*
I2c internal / GPM N.A. All N.A In Progress

Program Name Program Type* Card Technology* Card Printer Development Req*
All All All All Yes

Priority* Requested By Client Expected Completed On Classification*

(Launch Critical,High,Normal)
Delivery Date (MM/DD/YYYY) (A, B)
Normal Solutions Release 22.5 A

Ticket ID* Business Analyst* Solution Architect* Client Manager Project Manager
11247242 Khurram Munir Usman Tariq
Sheikh/Irfan Ahmed

3
2. Ticket Description

When holding deposits for account holders, allowing them to name a beneficiary is important for
the resolution of funds held should the accountholder pass away.

Enable the addition of, display, update and storing of beneficiary assigned to DDA accounts by
accountholder. The account holder should be able to access/modify this information. Also allow for
C-Agent capabilities to add/maintain Beneficiary information. API will need to be updated as well.

UC# Pri Tic Functio Description

ori ket nal
ty # Req?
11.1.1 Enable Beneficiary Information
11.1.1.1 In order to allow for accountholders to assign a beneficiary,
enable the ability to add beneficiary information at the account
level. Information to be added:
 Beneficiary Name
 Address
 Address 2 (Optional)
 City, State, ZIP
 Phone 1
 Phone 2
 SSN
 Date of Birth
11.1.1.2 Update display and edit on C-Holder

4
11.1.1.3 Beneficiary is information only. Should the
Accountholder pass, upon notification of death, enable
the beneficiary to either a) Move the Beneficiary as the
account holder or b) Open a new account for Beneficiary
and move funds to that account.
11.1.1.4 Fields should be available to add and update via API calls.
Enabling addition of Beneficiary information and update
capability.
11.1.1.5 Update C-Agent to enable the maintenance of Beneficiary
information on behalf of account holder.

Sample:

11.1.2 Enter use case title here

11.1.2.1

5
 11.1.2.2

11.1.2.3

11.1.2.4
11.1.2.5

3. Scope of Work (Internal)

Change Detail: As per the use case, the GPM Team has requested to implement a core banking feature in i2c
system. Th cardholder should have provision in the System to nominate a beneficiary. The beneficiary should
have provisions to access the cardholder account when the cardholder is marked as deceased in the system.

Current Limitation: Currently in i2c applications the cardholder can not nominate a beneficiary which can be
linked with the cardholder account.

Detail Flow:

1. There should be provision in the system (C-holder (Web/Mobile) / API) that user can nominate a
beneficiary.

2. Beneficiary may be added based on provided beneficiary profile information. To name a few system shall be
asking the intended beneficiary to provide information based on his “Beneficiary Name”, “Address”,”City,
State, ZIP”, “Country” “Contact Number”, “Identification Number”, “Mother Maiden Name” and “Date of
Birth” and many other etc.

3. System shall be verifying the beneficiary through Verification processes namely, CIP, OFAC and or through
internal/external hosts.

4. The system should not allow cardholder to nominate more than one beneficiaries.

5. Once the beneficiary has been verified the system shall be provisionally linking the beneficiary with
cardholder account. User can update / remove the beneficiary through C-holder, C-Agent and API.

6. Beneficiary shall be able to access the cardholder account once the cardholder is marked as deceased after
complete verification Process (through C-Agent). List of Questions to be asked by agent for further verification.

6.1 System shall be creating a card (on Demand) on which the Customer Service Agent can transfer funds from
deceased person account after is due consent. Address and other information of the cardholder can be
changed during the on Demand Card Generation.

6.1.1 Deceased Person card shall be marked as Closed with All Cash out. Note Cash-out shall be on the
discretion of Program Manager by issuing check or by generating the card for the Beneficiary (whether already
exist in the system or does not exist in the system)

6
6.2 If the beneficiary already in the system as a cardholder, then system shall be transferring funds to his or
her existing card after is due consent.

6.3 Upon Request of the Beneficiary, the agent can also transfer funds from the deceased card account to the
beneficiary Bank Account. The bank account can outside i2c i.e. the beneficiary card may not be existing in the
system. [Ask Card Program Manager to give check to Beneficiary]

6.4 There should be provision in the system that the funds can be loaded to Beneficiary even if the cardholder
is not marked as deceased.

4. Functional Requirements

Following are salient Functional Requirement with respect to ticket.

1. User should have the provisions to define and associate a beneficiary with a cardholder.
2. There should be provisions in the system to manage the added beneficiary i.e. the beneficiary can be
updated and deleted (disassociated) with the Cardholder.
3. System should also proceed to verify the beneficiary through CIP and KYC Processes just like a
cardholder.
4. There should be provisions in the system to disassociate users from various interfaces.
5. The Cardholder should be allowed to associate N number of beneficiaries (N should be ~= 2)
6. The Beneficiary shall not be having any provisions to access the cardholder account unless or until the
cardholder is not marked as deceased.
7. For moving funds to the Beneficiary Account system should proceed to create beneficiary account /
card and then funds should be moved to that card. i.e. Beneficiary card must be created for funds
movement.
8. Once the funds have been completely (All Cash-out) moved from the “Deceased Persons card” to the
Beneficiary (Account) then system should proceed to close the Deceased Person card.
9. If the beneficiary already have a card in the system then the Agent user should be having provisions to
transfer funds with Card to Card Transfer.

5. Non-Functional Requirements
Any Non function requirements like, performance, security or usability will be mentioned in this section

7
6. Solution Details
6.1 Proposed Solution

C-Holder Web / Mobile.

A new screen has been proposed in C-Holder Web / Mobile. wherein, user can define the Beneficiary;
following are operational processes involved in defining a beneficiary.

C-Holder Web Mocks:

https://www.figma.com/proto/2KdTy6hmbQUvuif8DnXyAp/11247242---Manage-Beneficiaries?
page-id=0%3A1&node-id=1%3A1979&viewport=1152%2C570%2C0.22&scaling=min-
zoom&starting-point-node-id=1%3A1979

• The newly “Proposed Module” shall be under “Settings” and its name should be “Manage
Beneficiary”
• When user clicks “Manage Beneficiary”, the landing screen should be showing a list of
Beneficiary / Nominees. If there is no nominee in the screen then system should be showing
information message “You have not added any beneficiary yet”. Figma Mock # 1.
• User can define a New Beneficiary by clicking the Add button [Mock #1]. A form should be
shown and following fields should be shown dynamically.

Personal Information: First Name, Last Name, Date of Birth, Mother Maiden Name, Identification
Number, Relationship
Contact Details: Mobile Number, Home Phone Number, Email Address, Mailing Address

Please refer to Mock # 2 and # 3 in Figma link shared above. Sequence of the fields should be as
mentioned above.

Note: The above stated fields are the recommended fields and it is at the discretion of Card Program
Manager to reduce the available fields as per requirements.

• User shall be accepting the Terms and Conditions. As per discussion with Compliance Team, Program
Manager shall be defining the Terms and Conditions from existing implementation and these T&C will
be shown as per the mocks.

• The fields should be dynamically changeable on the discretion of Card Program Manager (Add and
Remove fields based on validation criteria). i.e. If user only wants to show “Beneficiary Name”,

8
 “Address”, “Mobile No” then system should only show these three fields and beneficiary should be
added in the system with these three fields only.

• Once the user has specified all the valid input data then system should proceed to save the
beneficiary when user clicks the save button. Figma Mock # 5

• Personal Information:
• All the fields in this section should be mandatory accept Middle Name.
• First Name, Middle Name, last Name shall not be having input greater than 50 characters.
• Format of information message when user does not provide any data shall be:
“Please provide First name”
“Please provide last name”.
“Please provide Mother Maiden Name”.
“Please provide SSN as Identification Number”
“Please provide Foreign ID as Identification Number”
“Please provide email address”
In case user provides invalid email address then application should give error message.
“Please provide valid email address, the email address is invalid”.
“Please select Date of Birth.
• The Nominee should have age above 18 years i.e. if current date is 31-Dec-2022 and Beneficiary Date
of Birth is 30th December 2006. Then system should not accept this as input value.
• Relationship dropdown should be listing all the relationships “Brother”, “Sister”, “Cousin”, “Brother in
Law”, “Sister in Law”, Uncle, Aunty, Father, Mother, Others. When user selects Others then an input
box should appear.

Sharing Basis:

• User can select “Sharing Basis” as a percentage value. i.e. user can provide percentage % value
between 0.01 and 100%

If user provides 0 as percentage or value greater than 100 then system should give error message:

“Please provide valid percentage basis”.

• If there is provisions to add only one then by default the “Sharing Basis” should be shown as 100%
and this field should not be available for user to view or edit.
• If there is a provision to add more than 1 beneficiary i.e. 2/3 or 4 then for each beneficiary the user
can define variable percentage basis. But the overall percentage should be 100%. i.e. if Beneficiary A
is assigned a sharing basis of 40 % then B should be set with 60%.

Example 1: If user gives percentage basis for first beneficiary as 40% then system should only allow
the user to save second beneficiary with 60 % and if user provides 40% again for the second
beneficiary, then system should be giving the error / information message:

Please provide percentage for the second beneficiary equal to 60%.

Note: In the above case the user should calculate the remaining percentage and should show on the
screen the remaining. 60% in the above case is an example.

9
 Example 2: Similarly in case of provisions to add 3 beneficiary: if user enters first two beneficiary with
percentage as 33.33 then the last one should be saved with 33.34 (but not less than or greater than
this)

Documentary Proof:

This field shall be optional and user should have provisions to add multiple documents but not infinite
documents.

• Documentary Proof shall be an Optional Field.

• Guideline / Help Text: “Here user can provide documentary proof e.g. relationship certificate, Birth
Certificate etc.

• For simplification, user should have the provisions to upload up to 10 documents. System should not
allow user to upload 11th document and should give valid error / information message:

You can not add more than 10 documents as a proof identification for this beneficiary.

• User can upload Images, PDF, Office application files from the file upload component.

• User should not have provisions to upload a document more than 10 MB. Application should give
error/information message: “Uploaded document should not be more than 10 MB in size”.
[Architect] can set the standard size.

• System should also check and verify the content of the files i.e. if Image file is uploaded then system
should verify that it is a valid image file and system should check the file header, content and
checksum. Similarly, sanity of Word, Excel and PDF should also be assured.

• If user provides invalid file whether the content of the file is invalid or file is corrupt then system
should show error message:

“Invalid File Format, please provide the correct format”.

Terms and Condition:

• System should not allow saving beneficiary without accepting the “Terms and Conditions”.
Application should give error message:

“Please acknowledge Terms and Conditions to proceed further”.

• The T&C button will be visible when user scrolls through the complete list of T&C.

• Once the Beneficiary has been saved the screen should be showing success message “Your
Beneficiary has been added successfully.” Mock # 7
• C-Admin: There should be Provision in the system to add one or more than one Beneficiaries
associated with the Card. User should be able to add Maximum of Two Beneficiaries and this
operation should be controlled through Parameter which can be applicable on System and Card
Program Level. The Proposed Beneficiary Parameter name should be AlowBeneficiaryAddition

10
 Abbreviation:AlwBnficryAditon

Description: Maximum Number of Beneficiaries to be allowed to associate with the Card holder)
Acceptable values: 1,2,3…

CIP KYC of the beneficiary:

• There should be a configuration in the system (card program/system) to verify CIP / OFAC or KYC of
the Beneficiary.

→ If CIP/KYC fails then system should not proceed to save the beneficiary and system should state
following message: “Beneficiary can not be verified” and report the notification via an alert: see alerts
section for details.

→ CIP / KYC should check the Beneficiary Profile information for verification.

→ Beneficiary Verification CIP/KYC should be set at Card Program and Brand and Bin level.

→ Parameter Abbreviation/Name: “AlwBenfcryCIPKYC” – Allow Card-holder Beneficiary Verification.

→ Possible values 0,1,2

→ 0 mean check CIP / Ofac. Once ofac checks are passed the system should set the status as
“Verified” in case it fails then system should set the status as “Failed” and should also communicate
the failure reason through alert to the card-holder.
1 → No OFAC and CIP and System will save the beneficiary with “Verified” status
2-→ would mean Manual Verification would be required.
CSR will approve / reject the beneficiary from C-Agent for reference see C-Agent changes section.

→ The above parameter should be workable on Add / Update operations.

• With Manual Approval Process: System will initially log the beneficiary with “Logged” Status (Mock
#8). C-holder user should not have provisions to change the status.
User can also see other statuses for beneficiary i.e. Verified, Pending, Failed. Note: verified and
Pending shall be set from C-Agent as a Back Office Operation.
• C-holder user can also define beneficiary with “inactive” status.

• System will be charging a Service Fee upon successful insertion of beneficiary. The service name is
going to be BnfcryAdtnFee (Beneficiary Addition Fee).
• When a beneficiary is saved and successfully associated with the Card-holder, system should also
save necessary audit trail information i.e. date at which it was saved and updated and who updated it
from which interface (Cholder, C-Agent, API).

11
Alert Mechanism:
As soon as user adds the beneficiary, system will be notifying card-holder that the beneficiary has been added
successful. Alerts shall be Card program Alerts only. Following is the detail about various use cases:

Triggering Criteria: Real Time as soon as user Adds/Updates/Deletes/Fails a beneficiary.

Note transaction Reference Number will be a non financial transaction reference number.
Applications: C-Admin, C-holder (Web/Mobile)
Channel: Email / SMS /Mobile Push

Alert Type: CH_BENF_ADD

Alert Name: Add Beneficiary to Cardholder Account.

Subject: Beneficiary Setup Request

Body:
Your request to setup beneficiary “<<Beneficiary Name>>” against your card account “<<last 4 of card
number>>” has been successful submitted for review and approval. It will take 1 to 2 business days to further
verify the Beneficiary.

Date Time: Saturday, October 3, 2022

Transaction Ref. No: 1234567
For further inquiry, please contact customer services <<Customer Services Number>>.
Alert Type: CH_BENF_UPDATE

Alert Name: Beneficiary associated with Cardholder Account Updated.

Subject: Beneficiary detail Updated

Body:
The profile details of beneficiary “<<Beneficiary Name>>” associated with your card account “<<last 4 of card
number>>” has been updated in the system.
Date Time: Saturday, October 3, 2022
Transaction Ref. No: 1234567
For further inquiry, please contact customer services <<Customer Services Number>>.

Alert Type: CH_BENF_DELETED

12
Alert Name: Beneficiary associated with Cardholder Account Deleted.

Subject: Beneficiary Removed

Body:
The beneficiary “<<Beneficiary Name>>” associated with your card account “<<last 4 of card number>>” has
been removed.

Date Time: Saturday, October 3, 2022

Transaction Ref. No: 1234567
For further inquiry, please contact customer services <<Customer Services Number>>.

Alert Type: CH_BENF_FAILED

Alert Name: Beneficiary associated with Cardholder Account is not verified.

Subject: Beneficiary Request Rejected

Body:
Your request to link beneficiary “<<Beneficiary Name>>” with your card account “<<last 4 of card number>>”
has been rejected.

Date Time: Saturday, October 3, 2022

Transaction Ref. No: 1234567
For further inquiry, please contact customer services <<Customer Services Number>>.

Alert Type: CH_BENF_VERIFIED

Alert Name: Beneficiary associated with Cardholder Account has been verified.
Subject: Beneficiary Request Approved
Body:
Your request to link beneficiary “<<Beneficiary Name>>” with your card account “<<last 4 of card number>>”
has been approved.

Date Time: Saturday, October 3, 2022

Transaction Ref. No: 1234567
For further inquiry, please contact customer services <<Customer Services Number>>.

C-Holder Mobile Mocks:

13
https://www.figma.com/proto/Lg2IQwQRCEiqeGMpabQsiN/Manage-Beneficiaries---11247242?page-
id=0%3A1&node-id=1%3A1114&viewport=1892%2C762%2C0.44&scaling=min-zoom&starting-point-
node-id=1%3A821

• The Process flow and points in Mocks

Business rules shall remain same as defined in C-holder Web Section.

Change in C-Agent: In C-Agent Application the C-Agent user should have the provisions to do
following operations.

• Manage Beneficiary
• Funds Transfer from Deceased Cardholder to the Beneficiary Account.

14
 • This module shall be available in both in outside card search and inside card search.

Prerequisites: C-Agent user should have provision to Transfer Funds to the Beneficiary based on
following conditions.
1. Cardholder status (Card Status) has been marked as deceased. Agent can check deceased status
from Manage Card / User Screen after card search (After Card Search). [DD Team: Provide mocks as
per SRB note in the Search criteria only search can be made with respect to Card No, Card Program
and beneficiary status but no need for beneficiary names in the search criteria)
2. After Necessary Verification of the Beneficiary and other documentary Proofs. The agent shall be
having provisions to initiate funds transfer to the Beneficiary Account.
1. Setting Card Status
For changing the Status of the Cardholder, C-Agent Back (Office Operation) shall be used. User will
be changing the Card Status from “Change User / Card Status) as per existing implementation.
Change Detail: There is no change in the Process Flow and this is achievable through existing
implementation. This shall be mentioned in Impact Analysis.

2. Agent Defining Beneficiary (Outside Card Search)

Agent can define beneficiary on behalf of Customer / Cardholder through Card Program Manager.
Moreover, the agent can update an already added beneficiary by search beneficiary against the
Cardholder from C-Agent outside Card Search.
C-Agent Mocks
https://www.figma.com/proto/78zjn0FGGOMBwvfP9XoNX3/11247242---Beneficiary-on-C-Holder?page-
id=0%3A1&node-id=331%3A2555&viewport=843%2C-1549%2C0.27&scaling=min-zoom&starting-point-
node-id=331%3A3121

Outside Card Search (Change Detail):

User can search Beneficiary “outside card search” by providing search criteria i.e.
• User can search on the basis of Beneficiary Name, Beneficiary associated with a Cardholder
(Card Number, Card Reference Number), and also based on other profile data namely
“Mobile Number”, “Identification Number”, “Mother Maiden Name” and “Date of Birth”, Enrollment
Date and ID Number (SSN / Foreign ID).

• Agent can set the Status of the Beneficiary as “Verified”, “Pending Approval”, “Failed” and even
Logged as well.

→ Agent can define Beneficiary with any of the above listed statuses.

15
• User can edit an existing Beneficiary by clicking the view/edit link button.
• User can also “mark” an already defined Beneficiary with inactive status. User can mark status as
inactive in multi-select mode or in single mode. Mock #4.

• C-Agent user can not delete a beneficiary from the screen the only applicable operation would be
that a particular beneficiary can be marked as inactive. There will be a dropdown option to change
the status of the beneficiary [Mock #8 and #9]. DD Team will provide the updated mocks.

• Not in the mock, there should be another Section above “Personal Information”

Cardholder Status shall have two possible values: Deceased, Alive. The information shall be read-only.

16
# Field Name Data Type Valid information / Error Messages / Details
1. First Name AN100 If user does not provide Beneficiary Name then application
should give information message:

Please enter beneficiary First name

2. Last Name AN100 . If user does not provide Beneficiary Name then application
should give information message:

Please enter beneficiary Last name

3. Relationship Drop-down If user does not provide Information:
Please select Relationship
4. Home Phone Number AN 100 If user does not provide Information:

Please enter Home Phone Number.

5. Work Phone Number AN 100 If user does not provide Information:

Please enter Work Phone Number

6. Mobile Number AN 100 If user does not provide Information:

Please enter Mobile Phone Number

7. Mother Maiden Name AN 100 If user does not provide Information:

Please enter Mother Maiden Name

8. Status Drop-down If user does not provide Information:

Please select beneficiary status

9. Upload Documentary File Upload If user does not provide Information:
Proof
Please provide documentary Prove

Note: At least one Documentary Prove Must be provided

10 Address AN 500 If user does not provide Information:
.
Please provide Address

Note: Address Length 255 Characters. If it exceeds the fields

data should be truncated.

11 Country Drop-down If user does not provide Information:

Please select country

12 State Drop-down Please provide State

Note: States will be triggered against country if the State is

17
 not available then user will provide the state in the textfield.
13 Zip / Postal Code AN 30 If user does not provide Information:

Please provide Zip / Postal Code.

Business As usual: Validation on Zip / Postal Code should be

applicable.
14 Email Address AN 50 If user does not provide Information:

Please provide Email Address.

When Email address is not valid:

Email Address is not valid

Note: Already available regular expressions shall be applied.

15 ID Number AN 50 If user does not provide Information:

Please provide ID number

Note: Already available regular expressions shall be applied

for checking verification of valid ID Number format.
16 Date of Birth Calendar If user does not provide Information:
Control
Please select date of Birth.
17 Sharing Basis (%) Numeric(10,2) If user does not provide Information:

Please define sharing Basis Percentage.

Other validation Rules:

Sharing Basis Percentage can not be greater than 100%

Sharing Basis Percentage can not be less than 0%
Please enter valid Sharing Basis Percentage.

18 Active Checkbox This is used for marking beneficiary as inactive in the system.
.

Table 1

18
 • User can also update the Beneficiary information on behalf of card-holder after necessary
verification.
- Firstly, the C-Agent shall be verifying the cardholder / Card associated with the beneficiary has been
marked as Deceased.
- Agent shall be verifying the beneficiary information from his profile fields namely, Mother Maiden
Name, Age, Contact Information along with the questions from attached documentary proofs.

Inside Card Search

Inside card search user will get into cardholder flow by giving existing information on card search e.g. SSN/ ID
of the deceased cardholder/Date of Birth and Cardholder Name and others.

https://www.figma.com/proto/78zjn0FGGOMBwvfP9XoNX3/11247242---Beneficiary-on-C-Holder?page-
id=0%3A1&node-id=332%3A4364&viewport=805%2C-2905%2C0.42&scaling=min-zoom&starting-point-
node-id=332%3A4364&show-proto-sidebar=1

• C-Agent (Supervisor) shall have the provisions to Add / edit / remove beneficiary after card search.
• On Card Summary there will be a grid to show beneficiaries associated with the card-balance.
• User can Add Beneficiary: Validation rules are applicable as per the grid mentioned in C-holder
Section Table 1. User shall be clicking Add Beneficiary on “Card holder beneficiary” screen #2 and
then proceed to Add Beneficiary mock #3 and #4.
• After successfully addition of the beneficiary it will be shown in a grid on mock # 5.
• User can edit an existing beneficiary and make the necessary changes, In edit Beneficiary the
comments field will be mandatory. Operation / Business rules related to edit beneficiary shall remain
the same.
• After successful search operation, user can proceed to transfer funds to the beneficiary by clicking
“Transfer” link button against a beneficiary. A Popup up screen shall open. Following are few
information message with respect to Available Balance and Transferable Amount.
◦ Available Balance shall be read-only information. User can transfer full or partial amount by
entering amount in “Transferable Amount” field.
◦ The Available Balance shall be the Accumulated Balance of the Card which shall be including
Purses, Supplementary Card, Primary Card etc.

19
 ◦ The Amount in Transferable Amount field can not be lesser than 0 and can not be greater than
available amount.
◦ i.e. if there is 1 beneficiary (with 100%) limit then user can get full amount equal to the available
balance but not beyond that balance amount.
◦ In case of 1 beneficiary user can be given amounts in chunks but the accumulated amount shall
still not go beyond the available balance.
◦ In case there are two beneficiary each with 50% share/shareable amount, and if the cardholder
has USD 100 balance then each should be getting a maximum of USD 50 each.
◦ In case C-Agent (Super User) tried to assign USD 51 to the first user than system should not
proceed to take this amount and following information / error message shall be shown.
“The provided amount is greater than the available percentage shareable limit of the
beneficiary”
◦ Transferable Amount can not be greater than Available Balance of the card-holder.
Transferable Amount can not be lesser than 0.
◦ If beneficiary does not have a Card then system will be proceeding to generate the card of the
beneficiary and the funds will be transferred accordingly. [DD Mocks]
◦ If a particular instance does not have ACH then Card to Bank operation should not be available
and only channel to funds transfer would be ALL Cashout and Card to Card Transfer. [DD Mocks]
◦ There will be another link for AllCashout Operation i.e. System will take all the cash from
Deceased Cardholder’s card and CSR will be adding necessary comments and information
(AllCashout) to transfer the funds to the beneficiary via cheque or other means outside the
system. [DD Mocks]

◦ When the funds are successfully transferred to the beneficiary then system will be locking
transaction with Service ID: Beneficiay_Fund_Transferred (Funds Transfer to the Beneficiary
from deceased Cardholder Account)

Note: Digital Design Team will provide the required mocks.

• All the fields in Funds Transfer section (Popup Screen Mock 2) shall be mandatory except the Detail /
Description. [* Not Mentioned in the mocks.]
• User can review the information by clicking “Review” button. All the information in Review Screen will
be read-only. Mock # 2 in Popup.
• The Popup Screen shall be showing the transfer history where applicable [Not in the mocks (Inside
Card Search) – For reference please see screen shot below]

20
• When user clicks Transfer Funds button the funds will be transferred to the beneficiary account
through offline transaction processing (ACH and other modes of Transfer business as usual).
Following information message shall be shown: [Not in the mocks]
“Your funds transfer has been scheduled to the beneficiary account. Processing time will be 1 to 2
working days”.
• View Details: When user clicks the “View Details” link button the screen shows three sub-sections 1.
- Cardholder Details, Beneficiary Details, Transfer History in read-only format.
- Transfer History shall be showing the successful transactions and unsuccessful ones to the
Beneficiary.
- Other statuses shall be “Scheduled”, “Successful”, “In-progress’, “Failed” and all the statuses
applicable to ACH can be shown here.

• In View mode there should be an option for Funds Transfer. User can Transfer Funds through this
Screen. Mock # 5.
• User can also add comments from the Mock # 5 in view mode but rest of the fields should be non-
editable.
• After necessary verification user can proceed to transfer funds to the card-holders beneficiary by
clicking Transfer Funds button from Mock # 5.
• On clicking Transfer Funds button as stated in the above point. A Popup Screen shall open as per
Mock # 6. User can take bank account information from the beneficiary and can input the information
about bank account. All the validation checks on Fields namely, Bank Account Number, Routing
Number, Account Title shall be applicable as per current implementation in MCP Application. Mock
#6
• User can preview / review the bank account information of the beneficiary (Mock # 6) before actual
funds transfer.
• On clicking Funds Transfer button, system will initiate Card to Bank Transfer in the system which will
be processed through Back-end routine. Mock #6.
The screen shall be giving information message [use below message instead of the mock]
You transaction have been initiated it will take 1 to 2 business days to process completely.
• Against the Cardholder Beneficiaries screen – System will maintain the funds transfer activities either
failed or successful as shown in the mock # 5 in Transfer History Screen.
• Against the Cardholder Beneficiary user can also add Card Comments as shown in Mock # 5 Card
Comment. This comment of Add Comment shall be same as per existing implementation. System will
also maintain the comments as per existing framework. Mock # 5.

21
• User can also update comments Mock # 12.
• Once the Transaction have been initiated it will be logged with Logged Status.
• If there is an error while processing the transaction. Following error message shall be show:
“Your Request can not be processed at the moment, please try later.”
• Asterisk marked in Red shows that the Field is Mandatory. Following shall be validation messages if
user does not enters the data in the fields. Refer to Table 1 below:
• On Transfer funds screen following error / information messages shall be applicable. Field
information is given in Table 2. Note all the fields are mandatory [Note: marked as Mandatory in the
mocks]
Information Message:
The Bank Account Number you have entered is invalid.
The Account Number you have entered is invalid.
The Routing Number you have entered is invalid.
Please enter valid Transferable Amount.
• User can also view the details of the Pending Transaction by clicking the View Button.
• Once the initiated transaction has been posted successfully. Then system should be showing the
Transaction ID. User can see the Detail of transaction by clicking the Transaction Details[In a Popup,
Not in the Mock]
• C-Agent user can add comments at any point in both view and edit mode. In view it is required when
the C-Agent user has verified the Beneficiary and adds some comments. In Edit mode it is required
when C-Agent user has made some changes in the beneficiary and adds a card comments against this
operations.
• In case of any Error system should be showing error in the processing of the Card to Bank
Transaction, system should be showing reason of the failure as shown in below mock. Not in the
figma mocks. Field Name shall be “Decline Reason” as shown in below snapshot.

• Not in the mock, there should be another Section above “Personal Information”

Cardholder Status shall have two possible values: Deceased, Alive. The information shall be read-only.

22
# Field Name Data Type Valid information / Error Messages / Details
1. Bank Account Number AN100 If user does not provide Bank Account Name then application
should give information message:

Please enter Bank Account Number

2. Transferable Amount Currency If user does not provide Information:

Please provide Transferable Amount

3. Account Nick AN50 If user does not provide Information:

Please provide Account Nick

4. Account Title AN100 If user does not provide Information:

Please provide Account Title

5. Bank Name AN100 Please provide Bank Name
6. Routing Number AN20 Please provide Routing Number
7. Account Type Drop-down Please select Account Type.
8. Detail Description AN 1000 Please provide Detail Description / Notes.
9. Scheduled Transfer Drop-down Please select Scheduled Transfer Date
Date

• In case of Auth-Host Client. The Agent shall be doing “All Cashout” from C-Agent and then writing an
email to the Card Program Manager to provide funds to the Cardholder through Cheque or Manual
Process. AllCashout Functionality is already available in C-Agent.
• If the Card is Auth Host then system should be giving error message.
Information Message:

Funds can not be transferred to the Cardholder. This should be communicated to the Issuer to Issue
the required amount to the beneficiary.

Web Services API Related Changes.

Two different sets of services shall be required, 1. Manage Beneficiary, 2. Funds Transfer to beneficiary. For
the later case we can use existing API of Card to Bank Transfer and Create Bank Account. For the former one
we need to develop new sets of Services.

23
CreateCardHolderBeneficiary
This service shall be associated with a cardholder, user shall be providing cardholder (card reference number/
card number and follow it up with beneficiary information to create a beneficiary for the cardholder. Following
shall be Code Snippet for creating a beneficiary in the system.
{
"createCardholderBeneficiary":{
"acquirer":{
"id":"",
"userId":"",
"password":"",
"arn":"",
"additional":{
"Data1":"",
"Data2":"",
"Data3":""
}
},
"cardAcceptor":{
"id":"",
"nameAndLocation":"",
"mcc":"",
"deviceId":"",
"deviceType":"",
"localDateTime":"",
"clerkId":"",
"interfaceId":""
},
"card":{
"number":"",
"referenceId":"",
"customerId":""
},
"BeneficiaryDetail":{
"Beneficiary FirstName":"",
"Beneficiary LastName":"",
"Beneficiary MiddleName":"",
“Relationship”,””
“MotherMaidenName”,””
“BeneficiaryDOB”,””
"Address":"",
"City":"",
"State":"",
"ZipCode":"",
"Country":"",
"HomePhone":"",
"WorkPhone":"",
"MobilePhone":"",
"IdentificationNo":"",
"EmailID":"",
“BeneficiaryStatus”:

},
"applyFee":""
}
}

24
TAG Data Default Req Description
Beneficiary AN50 N/A Y Beneficiary First Name
FirstName
Beneficiary AN50 N/A Y Beneficiary Last Name
lastName
Beneficiary AN50 N/A Y Beneficiary Middle Name
MiddleName
Relationship AN50 N/A Y Relationship of Beneficiary with Cardholder
MotherMaidenNam AN50 N/A Y Mother Name of Beneficiary
e
BeneficiaryDOB AN10 N/A Date of Birth (mm/dd/yyyy)
Address AN100 N/A Y Address / Location of the Beneficiary
City AN50 N/A Y City of the Beneficiary
State AN20 N/A Y State of residence of the Beneficiary
Country AN50 N/A Y Country of Residence of the Beneficiary
HomePhone AN50 N/A Y Home Phone Number of the Beneficiary
WorkPhone AN50 N/A Y Work Phone Number of the Beneficiary
MobileNo AN50 N/A Y Mobile Phone Number of the Beneficiary
IdentificationNum AN50 N/A Y It can be SSN for USA and for other countries
their ID Numbers where ever applicable
ApplyFee AN1 N/A N Whether to Apply Fee
BeneficiaryStatus AN50 NA N By Default the system will write “Logged”. The
Specified values are “Verified”, “Rejected”,
“Failed”

{
"createCardholderBeneficiaryResponse":{

"responseCode": "",
"responseDesc": "",
"beneficiaryId": "",
"transId": ""

TAG Data Default Req Description

25
ResponseCode AN 4 NA Response code sent from the MCP server.
See Appendix Response Codes for details.
ResponseDesc String NA Response code description or the response
message.
TransID XN11 NA Identifier code for the transaction.
BeneficiaryID XN11 NA Beneficiary Id Returned by System to be used
for Update and Remove the Beneficiary ID

UpdateCardholderBeneficiary:
All the Fields mentioned in CreateCardholderBeneficiary shall be extendable to UpdateCardholderBeneficiary.
User shall be using the beneficiaryID to update the beneficiary of the cardholder.

{
"UpdateCardholderBeneficiary":{
"acquirer":{
"id":"",
"userId":"",
"password":"",
"arn":"",
"additional":{
"Data1":"",
"Data2":"",
"Data3":""
}
},
"cardAcceptor":{
"id":"",
"nameAndLocation":"",
"mcc":"",
"deviceId":"",
"deviceType":"",
"localDateTime":"",
"clerkId":"",
"interfaceId":""
},
"card":{
"number":"",
"referenceId":"",
"customerId":""
“BeneficiaryId”:""
},
"BeneficiaryDetail":{
"Beneficiary FirstName":"",
"Beneficiary LastName":"",
"Beneficiary MiddleName":"",
“Relationship”,””
“MotherMaidenName”,””
“BeneficiaryDOB”,””
"Address":"",
"City":"",

26
"State":"",
"ZipCode":"",
"Country":"",
"HomePhone":"",
"WorkPhone":"",
"MobilePhone":"",
"IdentificationNo":"",
"EmailID":"
},
"applyFee":""
}
}

TAG Data Default Req Description

beneficiaryID AN50 N/A Y Unique Beneficiary ID that will be mandatory
and used for updating various fields along with
other Card Data elements CardNo,
CardReferenceNo, CustomerID

RemoveCardholderBeneficiary:
All the Fields mentioned in RemoveCardholderBeneficiary shall be extendable to
UpdateCardholderBeneficiary. User shall be using the beneficiaryID to update the beneficiary of the cardholder.

By Providing Card Number /Card Reference Number the System can remove all the beneficiary available by
Providing BeneficiaryId only the said benefiary.

{
"RemoveCardholderBeneficiary":{
"acquirer":{
"id":"",
"userId":"",
"password":"",
"arn":"",
"additional":{
"Data1":"",
"Data2":"",
"Data3":""
}
},
"cardAcceptor":{
"id":"",
"nameAndLocation":"",
"mcc":"",
"deviceId":"",
"deviceType":"",
"localDateTime":"",

27
"clerkId":"",
"interfaceId":""
},
"card":{
"number":"",
"referenceId":"",
"customerId":""
“BeneficiaryId”:""
},
"BeneficiaryDetail":{
"Beneficiary FirstName":"",
"Beneficiary LastName":"",
"Beneficiary MiddleName":"",
“Relationship”,””
“MotherMaidenName”,””
“BeneficiaryDOB”,””
"Address":"",
"City":"",
"State":"",
"ZipCode":"",
"Country":"",
"HomePhone":"",
"WorkPhone":"",
"MobilePhone":"",
"IdentificationNo":"",
"EmailID":"
},
"applyFee":""
}
}

TAG Data Default Req Description

beneficiaryID AN50 N/A Y Unique Beneficiary ID that will be mandatory
and used for updating various fields along
with other Card Data elements CardNo,
CardReferenceNo, CustomerID

GetBeneficiaryDetail API will be used to retrieve the complete data of the beneficiary already added in the
system against the card.

{
"GetBeneficiaryDetail":{
"acquirer":{
"id":"",
"userId":"",
"password":"",
"arn":"",
"additional":{
"Data1":"",
"Data2":"",
"Data3":""

28
}
},
"cardAcceptor":{
"id":"",
"nameAndLocation":"",
"mcc":"",
"deviceId":"",
"deviceType":"",
"localDateTime":"",
"clerkId":"",
"interfaceId":""
},
"card":{
"number":"",
"referenceId":"",
"customerId":""
“BeneficiaryId”:""
},
"applyFee":""
}
}

UpdateBeneficiaryStatus will be used to update the status of the beneficiary, note for architect UpdateBeneficiary
API listed above can also be used for the same purpose .

{
"UpdateBeneficiaryStatus":{
"acquirer":{
"id":"",
"userId":"",
"password":"",
"arn":"",
"additional":{
"Data1":"",
"Data2":"",
"Data3":""
}
},
"cardAcceptor":{
"id":"",
"nameAndLocation":"",
"mcc":"",
"deviceId":"",
"deviceType":"",
"localDateTime":"",
"clerkId":"",
"interfaceId":""
},
"card":{
"number":"",
"referenceId":"",
"customerId":""
“BeneficiaryId”:""
},
{
}

29
"applyFee":""
}
}

MCP Report Changes:

With in the scope of this ticket a new report has been proposed. This report will be available in MCP Admin
under Report Menu. The path will be “Beneficiary Details” → “Beneficiary Details and Transactions”. This
will be a new Menu in the system.

Group By: User can group by the report on following group by factors.
• Card No, Beneficiary Name
• Cardholder Name, Beneficiary Name
• Transaction Date
Report Format: The report will be available in following formats

• PDF
• Excels
• CSV with Header
• Other formats applicable as per existing framework

Filter Criteria
User can filter report based on following filter criteria:

• Card Number
• Card Reference No
• Customer ID
• Cardholder Name
• Beneficiary Name
• Mother Maiden Name
• Beneficiary Identification Number

Report Layout:
The report shall have following layout and structure:

30
Fields Detail
• Card Number: Masked Card No as per PCI Standard.
• Card Reference No: Applicable for Non-PCI Complaint
• Card Holder Name: Name of the cardholder
• Current Balance: The available Balance in the deceased cardholders
• Beneficiary Name: Name of the Beneficiary which cardholder has nominated.
• Relationship: Beneficiary relationship with the cardholder.
• Mother Maiden Name: Mother Maiden Name of the beneficiary
• Claimable Amount: The amount which beneficiary can claim from the cardholder
• Card No / Cheque / Bank Account: Transferred source it can be card no, Cheque / Bank Account
(Cheque and Bank Account will be a static text in this case)
• Transferred Amount: The Amount which has been transferred to the beneficiary Accounts
• Beneficiary Card: Card Number of the beneficiary applicable only in sharefund operation
• Transfer Date: The transaction date on which the funds are moved to the beneficiary

Below are data points filled in, when user performs All Cashout Operation.
• Bank Account No: Bank Account Number of the Beneficiary
• Routing No: Routing Number used for processing Card to Bank Transferable
• Bank Name: Name of the Bank where Beneficiary has the Account.

Reporting Filters: Activity Date (Date on which status of Beneficiary is set/updated), Beneficiary Status, Card
Program, Beneficiary Setup Date
• Report Order By: Card Program, Card Account Number, Beneficiary, Activity
• Report Group By: Card Program, Card Account Number, Beneficiary
• Report Layout: Activity (Status), Activity Date, Activity Time, Channel/Interface, User (Cardholder,
Agent, System etc.)

31
Status: Status of the Beneficiary
Enrollment Date: Date when the Beneficiary was enrolled in the system
Enrollment Time: Time when the Beneficiary was enrolled in the system
Issuing Channel: The interface / channel through which the beneficiary was added in the system.
Enrollment By: The user id who did this operation.

6.2 Alternate Solution(s) (Optional)

Not Applicable

6.3 Impact Analysis

• From C-Agent Change Card / User screen card status should be set to close with reason (Deceased
Customer) and after changing this status the C-Agent user shall be able to view the Card Status and
Card Status Reason from Card Summary Details Screen. This feature should be workable and
Prerequisites for assuring the fund movement to Beneficiary and to verify that the card-holder is
deceased before proceeding.
• From C-Agent Beneficiary Screen user can initiate a Card to Bank Funds Transfer. After initiation the
system should properly post the files to the concerned Bank for further processing. This operation
should be executed as an end to end flow / process.
• C-Agent shall be closing the Card through AllCashOut Operation. [As per existing Implementation]. i.e.
All Cashout Functionality should work seamlessly without any incurring impact.
• If the beneficiary Card exist in the system then after approval the agent can also transfer from
deceased card account to beneficiary card account. This Transaction should be shown in Beneficiary
Report and on the Beneficiary Screen.
• Webservices API for “Card to Bank Transfer” and “Create Bank Account” should work without any
impact for transferring amount from Deceased Person Card /PAN to the Beneficiary Account.

6.4 Design Notes (Optional)

Not Applicable

6.5 Client Reference(s) Requesting Similar Solution (Optional)

32
7. Acceptance Criteria
• System should create and associate beneficiary with an existing card from various interfaces, web /
mobile / C-Agent/Web Services.
• System should properly reflect changes in Beneficiary once it is changed from various interfaces web /
mobile / C-Agent/Web Services.
• Funds movement from Cardholder (Deceased) to the Beneficiary should be in an atomic transaction
and system should be transferring amount to the Beneficiary Account / Card.
• For Debit Cards the system should not allow funds movement for auth-host clients since their balances
are not maintained in i2c system. For this purpose, the C-Agent should be making any necessary
comments against beneficiary and then email to the Program Manager to Transfer Funds to the
beneficiary (through Email)
• ACH Scheduler Service should post the required amount to the beneficiary Cardholder Bank Account.
• Reports should be stating the Card to Bank in Existing Reports and the new proposed report.
• Beneficiary Detail and Transaction Processing (Done or not) should be shown in the proposed report.

8. Impacted Technology Areas

Technology Modules
Groups

✘ C-Holder Web C-Manager C-Cart

Web ✘ C-Agent C-Partner WebPOS
FastSettle Admin Engage

Mobile ✘ C-Holder Mobile ePOS

Interfaces ✘ MCP Web Services API Engage Web Services API

Devices IVRU

OLTP Online Transaction Processing Settlement Debit Platform

OLAP MCP Reports FastSettle Reports Engage Platform Reports

Card Generation Track Generation SSRP

Batch Alert Scheduler Campaign Scheduler mRay
Others ________________

33
9. Solution Category
Product Feature (Client)
✘ Product Feature (Internal)
Infrastructure/Engineering
Regulatory/ Compliance
Other

10. Billing Details

Billing Event(s)
[Text]
Processing Details
[Text]

11. Change Evaluation Checklist

11.1 Can the New functionality be used by all clients?
✘ Yes No NA
Comment: Standard product enhancement

11.2 Is 3rd Party/Network Integration Required?

Yes No ✘ NA
Comment: [Text]

11.3 Is a CSD Update Required?

Yes ✘ No NA
Please select the CSD(s) that must be updated. Select all Product Platforms or Product Types impacted by the
change in this SRD.
Product Platform Product Types
C-Holder Web Select all that apply:
C-Holder Mobile App Credit
Debit/ Prepaid
(C-Cart should be considered part of C-Holder for CSD documentation) Gift
Virtual
Others (specify):

34
 IVR (C-Touch) Credit
Debit/ Prepaid
Others (specify):
C-Partner Credit
Debit/ Prepaid
Others (specify):
WebPOS/ ePOS Debit/ Prepaid
Other (specify):
Others Specify:

11.4 Is User Manual/Guide update Required?

✘ Yes No

12. Release Notification

✘ External Only ✘ Internal Only
Cardholder can now define and nominate a beneficiary and upon the deceased status of the card-holder the
beneficiary can get the card-holder funds.

13. Approvals
SRB Meeting Date Approved
(MM/DD/YYYY)
Approval Disapproved
Status:
CEO Approval
Approved with Changes
Required:

13.1 SRB Notes/Instructions

[List important points discussed and agreed in solution SRB]

Approved On
Approved By:
(MM/DD/YYYY):
Completed On
Completed By:
(MM/DD/YYYY):

35
14. Reference Documents
Sr. # Document Name Reference URL (Alfresco/SVN)
1.

2.

36
 Island Drive, Suite 105, Redwood City, CA 94065

Direct: +1-650-593-5400, Fax: +1 650.593.5402

www.i2cinc.com
(ID-1015)

37