Functionality and Operational Process of Credit Cards

Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
Training Handbook for VisionPLUS
Functionality and Operational Process of Credit

Cards using VisionPLUS
0
Table of Contents
OBJECTIVE OF THIS DOCUMENT................................................................................2

OVERVIEW OF THE CREDIT CARD PROCESS.......................................................3
INTRODUCTION..................................................................................................................3
What are Credit Cards?...........................................................................................................................3
Types of Credit Cards...............................................................................................................................3
CREDIT CARD TRANSACTION PROCESS............................................................................3
Key Players..............................................................................................................................................3
Credit Card Transaction Cycle................................................................................................................5
How do different players make money?...................................................................................................6
Details of Players’ functions and economics...........................................................................................8
Details of Players’ functions and economics...........................................................................................8
USE OF VISIONPLUS FOR THE CREDIT CARD TRANSACTION PROCESS. .12
PRODUCT PLANNING.......................................................................................................13
APPLICATION PROCESSING..............................................................................................14
ACCOUNT SETUP.............................................................................................................16
ISSUE PROCESSING..........................................................................................................18
AUTHORIZATIONS............................................................................................................21
TRANSACTION ROUTING.................................................................................................24
TRANSACTION POSTING..................................................................................................26
STATEMENT PROCESSING................................................................................................31
PAYMENT PROCESSING...................................................................................................33
DELINQUENCY.................................................................................................................38
COLLECTIONS..................................................................................................................41
CHARGE OFFS.................................................................................................................45
CHARGEBACK PROCESSING............................................................................................47
CUSTOMER SERVICE........................................................................................................49
CUSTOMER COMMUNICATION.........................................................................................51
SYSTEM SECURITY..........................................................................................................53
FRAUD MANAGEMENT....................................................................................................54
APPENDICES..................................................................................................................55
APPENDIX A: INTEREST CALCULATION METHODS............................................................55
Appendix B: Interest Accrual and Charging Illustration...............................................55
1
Objective of This Document
Level 1 gave the user an overview of Consumer Credit, the various stages involved in the
lifecycle of any credit product and an introduction to the main modules in VisionPLUS.
The objective of Level 2 is to provide the user with greater details on handling of a
typical card transaction using VisionPLUS.
It has been structured so as to give the user an in-depth understanding of the complete
flow of any card transaction and how the various modules of VisionPLUS interact with
each other to facilitate the processing of the transaction.
The first part of the document provides a business overview of the Credit Card
transaction process and the key players involved, while the second part comprises of how
the transaction is handled by VisionPLUS using its various modules.
2
Overview Of The Credit Card Process
Introduction
What are Credit Cards?

Credit cards are a form of revolving consumer credit that has a specific amount
that can be borrowed against, in part or in full. As the outstanding balance is paid,
the available credit line is restored for use once again. Credit cards typically offer
a variety of other services as well, such as cash advances and convenience
checks.
Credit Cards can be issued either by banks or other non-banking financial entities
and are generally associated with the Visa or MasterCard organizations.
Types of Credit Cards

There are primarily 2 types of Credit Cards:
1. General Purpose Cards

General-purpose credit cards can be used at any merchant accepting
MasterCard or Visa credit cards.
2. Proprietary/Private label credit cards/Limited purpose cards

Proprietary or limited purpose or private label cards are associated with
the retailer issuing the card and can be used only in that retailer’s stores.
Credit Card Transaction Process
Key Players
In any Credit Card transaction, there are a number of players involved from the
time a purchase is made, till the time the bill is settled. The following are the key
players involved in any card transaction:
1. Customer: The user of the credit card.
2. Issuing Bank: The Issuing Bank maintains the customer relationship. It

solicits screens and issues the card to the approved consumer. It is
responsible for billing and collecting payments for all transactions made
on the credit card by the customer.
It also receives the transaction details from the Acquiring Bank and makes
the necessary authorizations for completing the transaction. It is also
3
responsible for making the settlement to the Acquiring Bank for all
transactions carried out by its cardholders.
3. Merchant: These are the retail stores, restaurants, airlines, mail order
companies, petrol pumps, travel agencies etc where payments can be
made using credit cards.
4. Acquiring Bank: The Acquiring Bank maintains the merchant

relationship. It solicits screens and accepts merchants into the program. It
provides support services for the merchant like accepting the credit card
transaction chargeslips from the merchants and crediting their accounts
with the required payments.
The Acquiring Bank installs terminals at the Merchant site, through which
card and transaction details for each transaction can be received by it and
in turn passed to the Issuer for validation and approval.
The Issuing Bank and the Acquiring Bank can be the same in many
instances.
5. Visa / MasterCard Associations: These are the associations that facilitate

the transaction processing and settlements between Issuers and Acquirers
across the world.
When credit cards were first introduced, banks had agreements with
certain merchants to accept the credit purchases of card holders. When a
purchase was made, the cardholder presented the card to the merchant,
who would copy the information on the card on to the sales slip and send
it to his bank. The purchase was credited to the merchant’s account in the
bank less the discount rate. However, a major drawback was that
cardholders could shop in their own geographic area and only at
merchants that their banks were able to sign up. To overcome this
drawback, Bank of America began forming licensing agreements with few
banks outside California to issue the BankAmericard, which in 1976
changed its name to Visa. In 1966, certain other banks got together in
Buffalo, New York, to form their own network, called the Interbank Card
Association – which is now known as MasterCard International.
As the Visa and MasterCard organizations gained prominence, most banks

no longer tried to enter the credit card field alone, but rather joined one of
the two that were already in existence. The banks agreed to issue cards
displaying both the individual bank name and a symbol signifying that the
bank was part of a larger network of banks agreeing to interchange
transactions. This interchange feature made the card more attractive to
merchants because of the greater pool of current and potential
cardholders.
4
By the early 1980’s, the Visa and MasterCard systems had expanded throughout
the world and today they dominate the bank credit card industry in a number of
countries. These associations perform the authorizations, clearing and settlement
that allow a bank credit card to be used at any merchant that is a member of the
association.
MasterCard International and Visa International are owned by member banks and
governed by separate boards of directors. Both MasterCard and Visa own and
operate international processing systems that provide capabilities to authorize
purchases and settle merchant and cardholder transactions. Visa and MasterCard
serve this function through networks and automation, bringing together the
collective resources of banks and other financial institutions.
Banks can become members of both Visa and MasterCard.
Credit Card Transaction Cycle

The following diagram depicts a typical credit card process cycle from the time a
consumer applies for a credit card, till the time the bill is settled for the purchases
made.
5. To network if the
6. To Issuer for acquiring bank is
Authorization. not the issuer.
VISA /
Issuing Bank Mastercard Acquiring
Network Bank
7. Validates the card 8. Routes
and available credit Authorization
limit and provides to Acquirer.
authorization.
1. Applies 2. Validates
for Card. information 9. Routes 4. Authorization
and provides Authorization Request if
card. to Merchant. purchase above
floor limit of
12. Makes 11. Raises merchant.
Payment Monthly Bill
on Bill. for all
transactions.
10. Provides goods and services.
Customer Merchant
3. Makes purchases using the card.
5
The process starts with the consumer applying for the credit card to the Issuing
Bank. The Issuing bank evaluates the application and after the required
verifications, issues a Visa / Mastercard credit card to him with a specified credit
limit. The card can then be used by the customer in any merchant store which
accepts Visa cards / MasterCards.
When the customer makes a purchase in a store using his/her credit card, the
merchant system refers the card and transaction details to its Acquiring bank, for
card verification and authorization of the transaction. This is done for all
transactions above the merchant’s floor limit, which is generally Rs. 100 - 500.
The Acquiring bank checks for the Issuer of the credit card on which the
transaction has been made. In case the Issuer is some other bank, it routes the
transaction to the Visa or the MasterCard network depending on which network
the card belongs to else the authorization process if carried out by the Acquirer
itself.
The Visa/MasterCard network then evaluates the card details and routes the card
and transaction details to the Issuer bank.
The Issuer bank in turn validates the card information received from the network
with the details it has stored in its systems. Having validated the card, the Issuer
then approves/declines the transaction based on the transaction value and the
available credit limit.
This authorization information is routed back to the merchant via the

Visa/MasterCard network and the Acquiring bank. The merchant then provides
the goods and services to the customer or declines the transaction if the
authorization was positive or negative, respectively.
How do different players make money?

There are different sources of income for the individual players in any card
transaction that takes place. The following are some of the income sources in a
card transaction:
1. Interchange Fees: The Acquirer pays the Issuer a small percentage (1-
1.6%) of the rupee transaction amount. This fee reimburses the Issuer for
the cost of processing the transaction and the free period between
settlement and payment. It contributes approximately 20% of the bank’s
credit card revenue.
The Acquirer pays the interchange fee to the issuer through the Visa /
MasterCard Settlement System. Interchange fees are set by the National
6
Associations. There is one set for VISA and another for MasterCard
transactions. The fee depends on the type of authorization, Merchant type,
Card type etc. The interchange fee is called Merit for MasterCard
transactions and EIRF (Electronic Interchange Reimbursement fee) for
Visa.
2. Merchant Discount: This is the fee the Acquirer charges the Merchant in
return for processing the transaction (handling cardholder purchases) and
the cost of the Interchange fee. The Merchant Discount is generally about
(1.7 – 4%) of the transaction amount and depends on the Nature of the
Card, Merchant Sales, and the realization period for the chargeslips.
3. Interest Charge: This is the charge that the Issuer levies on the
Cardholder on the unpaid monthly balances. This is approximately 20-
36% per annum and is also called the ‘Annual Percentage Rate (APR)’.
This is the largest source of income for the Issuer and contributes to about
70-75% of the total income.
4. Annual Fees: This is the fee the cardholder pays to the issuer for the right
to carry and use the bank credit card. This accounts for approximately 5%
of credit card revenue for the Issuer.
5. Service Fees: This is the fees that the Visa and MasterCard associations
charge the member banks for providing the clearing and settlement
networks and undertaking other services like arbitration, stand-in
authorizations etc.
Visa / MC
Merchant Acquirer Issuer Customer
N/w
Customer makes Acquirer deducts Issuer deducts Makes the payment

a purchase of Merchant Discount of Interchange Fees of of Rs.10, 000 at the
10,000 using 4% (Rs. 400) and credits 1.5% (Rs. 150) and end of the month
Credit Card. merchant account with gives Rs. 9850 to upon receipt of the
Merchant passes Rs. 9600. Acquirer via Visa/MC bill.
the Rs. 10,000 Acquirer passes charge settlement n/w. In case of late
charge slip to his slip of Rs. 10,000 to Bills the customer for payment, interest
Acquiring Bank. Issuer through Visa/MC the Rs. 10,000 charges will also
n/w. purchase at the end of have to be paid.
the month.
10000 – 400 -9600 + (10000-150) -9850 + 10000 -10000

=9600 =250 =150
7
8
Details of Players’ functions and economics
1. Issuer Bank
Advantages to Issuer Bank

 Credit cards give banks the opportunity to attract customers who
do not live nearby. With a credit card, the bank’s location is
irrelevant. Then can thus increase their market areas.
 Banks can use this remote feature to expand their market areas.
 Credit can be extended via mail and phone.
 New cardholders make excellent prospects for cross-selling
additional bank products.
 Banks’ outstanding loans grow quickly as a result of credit card
programs.
Functions / Business Roles

 Administration (management of business).
 Marketing (cardholder solicitation and activation programs).
 Credit evaluation.
 Application processing.
 Credit processing (credit decision and set up of new accounts).
 Card issuance (embossing, encoding, issuing plastic cards).
 Incoming interchange (processing incoming cardholder
transactions and cardholder chargebacks).
 Cardholder billing (preparing and mailing cardholder remittances).
 Payment processing (processing, posting cardholder remittances)
 Customer service (handling cardholder inquiries, complaints).
 Overlimit (monitoring, resolving overlimit account situations)
 Collections (collecting outstanding dues from delinquent accounts)
 Fraud control (handling reports of lost or stolen cards and
reviewing activity on blocked accounts)
 Cardholder authorization (updating cardholder Masterfile with
Authorization requests, and liaison with the National
Associations, which process the majority of Authorization
requests).
Revenue side of Issuer economics

 Interest income
 Interchange income
 Annual membership fees
 Other fees and income – represents charges and revenue generated
by activities like Cash Advance Fees, Balance Transfer Fees,
Credit Insurance, Revenue from selling Merchandise, Exception
Processing Fees, etc.
9
Expenses
 Cost of Funds (interest paid to get funds)
 Loss / Bad Debts
 Servicing Expenses (‘front end’)
 Processing Expenses (‘back end’)
 Marketing Expenses (for acquiring new accounts)
 Collection Expenses
2. Issuer Processor
There are several alternatives that banks (Issuers) can adopt.

 Large banks, may opt for an ‘in-house’ unit for all the services.
 Regional associations formed by a consortium of geographically
linked banks is another alternative.
 Increasingly, many banks are choosing outsourcing to provide
front end and / back end support.
Thus some of the functions of the Issuer Processor could include:

 Marketing (cardholder solicitation)
 Credit evaluation
 Card issuance (embossing, encoding, issuing plastic cards)
 Cardholder billing / Statementing (preparing, mailing cardholder
bills)
 Data processing
 Customer service (handling cardholder inquiries, complaints)
 Collections (collecting outstanding dues from delinquent accounts)
3. Acquirer Bank
Advantages
 Merchants pay discounts to banks for handling cardholders’
purchases.
 In addition to discount income, merchants bring additional
deposits to banks. The merchant sales draft is treated as a deposit
item, thus becoming new sources of funds for making loans.
Functions / Business Roles

 Center administration (overall administration and control of
merchant relationships)
 Proof and capture (processing, reconciling all credit transactions
made at the merchant outlets and deposited to the merchant
account)
10
 Outgoing interchange (processing outgoing sales drafts and cash

disbursements upon completion proof and capture, handling
merchant chargebacks, and data retrieval requests)
 Risk management (processing new merchant applications and
assuring the credit worthiness of new and existing merchants,
monitoring merchants for suspected fraudulent activity)
 Merchant sales (soliciting and signing up new merchants and
providing both in house and filed support to the merchant base.)
 Merchant authorization (providing timely response to electronic
and voice authorization requests from member merchants)
Revenue side of Acquirer economics

 Merchant discount
 Earnings on deposits – net interest earned on merchant checking
account deposits
 Other income – revenue generated from such items as the
sale/rental of point-of-sale (POS) terminals and imprinters,
monthly fees and application fees.
Expenses
 Processing Expenses
 Sales and Marketing Expenses
 Outgoing Interchange
 Credit and Fraud Losses
4. Acquirer Bank
Some of the Acquirer activities can be out sourced. They include:
 Data Processing
 Credit evaluation
 Voice Authorizations
5. Credit Card Holder

 Convenience of purchasing goods and services.
 Wide acceptance by many merchant establishments.
 Freedom to use credit without having to go to the bank to apply for
a loan that would then have to be repaid with a monthly payment.
 Amount of credit used can be paid in full by the payment due date
or can be repaid in flexible monthly installments.
 Payment on purchases can be delayed for about one month.
 Offer a comparatively safe means of conducting transactions. The
potential loss is much lesser than if currency is lost or stolen.
 Facilitate internet / mail order shopping.
 Credit cards facilitate record keeping.
11
6. Merchants
 Credit cards make it easier for consumers to purchase goods, thus

boosting merchants’ sales.
 Consumers are more likely to make larger purchases when credit is
used instead of cash.
 MasterCard or Visa brand identification extending to merchants
increases the likelihood that customers will seek out and patronize
merchants that accept the card.
 Sales transactions are fairly easy to validate.
 The merchant has none of the risks inherent in extending credit or
accepting checks.
 No necessity for the merchant to contact a purchaser directly in an
attempt to collect money. By following the proper procedure, the sale
is validated, and the merchant receives payment from its bank.
7. VISA / MasterCard Associations
Business Roles/ Functions

 Licensing
 Setting operating regulations
 Standardizing interchange, clearing and settlement procedures
 Perform Authorizations for Merchant members
 Processing cardholder and merchant transactions
 Provide members with marketing, advertising support
 Assist in security & fraud control
VISA/ Mastercard
 The systems for authorizing transactions are INAS for MasterCard
and Base I for VISA.
 The systems for settling Merchant and Cardholder transactions are
INET for MasterCard and Base II for VISA
 The bulk data transfer systems that process cardholder and
merchant transactions (payment billing), including currency
conversion are BankNet for MasterCard and VisaNet for Visa
International
Revenue
 Fees charged to member banks based largely on bank card
volumes
 Assessments
12
Use Of VisionPLUS For The Credit Card Transaction Process

This section talks at a conceptual level about how VisionPLUS and its various modules
are used for handling the various phases in the credit card transaction process. The
section covers the entire credit card procedure end to end, in terms of how the various
modules of VisionPLUS deal with the respective phases and interact with each other.
For ease of understanding, the entire process has been broken down into the following
major phases:
 Product Planning
 Application Processing
 Account Setup
 Issue Processing
 Authorizations
 Transaction Routing
 Transaction Posting
 Statement Processing
 Payment Processing
 Delinquency
 Collections
 ChargeOffs
 ChargeBack Processing
 Customer Service
 Customer Communication
 System Security
 Fraud Management
13
Product Planning
This procedure involves business decisions taken by the organization in terms of which
credit product it wants to offer and the target market it wants to cater to. VisionPLUS
does not specifically have any module that aids an organization in planning the type of
credit product it wants to provide. This is purely a business decision that needs to be
taken by the organization’s management.
However, once the business decides the credit product that it wants to deal in,
VisionPLUS serves as a tool that allows the organization to store valuable information
about the credit product, its customers, customer details, transaction details etc. This data
can be translated into input information when the organization plans for its future
products in the same geography.
For e.g., the data can be used to draw out the past behavior of the customers and predict
the future behavior as well based on the past trends, it can be used to find out the
delinquent customers based on the payment history and the transaction details. The
various modules in VisionPLUS hence serve as an MIS that allow the organization to
take strategic decisions based on the existing customer base that it possesses.
14
Application Processing
Once the organization decides which credit product it wants to offer, application forms
have to be designed and sent across to capture details of the customers who are interested
in applying. This can be by direct mailers to a pre approved list of customers or by
placing the applications at various stores, banks etc. Having received the completed
applications, they are evaluated and scored and then either accepted or rejected for
issuing cards. For applications that have been accepted, decisions regarding the credit
limit to be made available have to be taken.
The Credit Decision Management (CDM) module in VisionPLUS handles Application

Processing. It aids in application design and application processing. There are a sequence
of steps that are followed in CDM for tracking and processing applications:
Processing Applications using CDM

The following are the steps that are followed for processing applications forms in CDM:
 Application Design: CDM has the flexibility to design the format of the
application forms that will be used to capture customer information. The
format matches the sequence of the printed applications.
 Application Input: Having received filled up application forms, the
information can be entered into CDM either manually into the Application
Input Screens, or loading files from external systems.
 Application Edit: For forms received from external sources, the edit process
needs to be performed in order to check for missing data. If missing data
fields are found, the system places it in the operator’s queue for his action.
 Pre-validation Process: In this step, the application form is checked against
the policy issues of the organization to determine if it meets the minimum
requirements for credit.
 Cross Check Process: Here internal and external cross checks are made with
the data on the application form to determine if the information matches.
 Application Scoring: Weights are assigned to the individual fields on the
application form and total points accumulated by each form are calculated.
Based on the cut off scores, the application is passed to the next stage or
rejected.
 Data Verification Process: There may be certain fields on the application that
require the operator to call and verify with the applicant over the phone or
letter.
 Credit Bureau Scoring: Credit Bureau information for each application is
sought and once received, it is scored. Depending on this score, the
application is either passed onto the next stage or declined.
 Combined Score: The application score and the bureau scores are used to
generate a combined score for the application. Based on the cutoff, the
application is either passed on or rejected.
 Final Judgement Process: The system applies any final criteria or policies on
applications that have reached this stage to pass them or decline them.
15
 Setup: Approved applications can be set up as accounts in the CMS module.

CDM interfaces with CMS in order to setup accounts. The following is the
minimum information passed from CDM to CMS in-order to setup the
account.
CDM Field CMS file affected

Customer Name Name and Address record (AMNA)
Organization Account Base Segment Record (AMBS)
Logo Account Base Segment Record (AMBS)
Account Number Account Base Segment Record (AMBS)
Billing Cycle Account Base Segment Record (AMBS)
State of Issuance Account Base Segment Record (AMBS)
Apart from the inherent risk that an application holds, the source from where the
application has been picked up by the customer plays a vital role in deciding for/against
an application. The source code holds this information in a 19-digit field. The source
allows the organization to determine whether the application was filled out with a serious
intention to purchase a credit product or not. It also enables the organization to determine
the hit ratio that it has received in reaching out to the customers. This later on can be
used in deciding whether that particular source has been beneficial in penetrating the
market to its fullest. The organization can hence decide whether it would want to include
it in its next marketing campaign.
16
Account Setup
Once an application has been approved and the Issuer has decided to provide the
customer with a credit product, an account is created in the customer’s name that records
the various transactions done on that particular card. All account related information is
stored in the Credit Management System (CMS) module of VisionPLUS.
The following are the various keys created for the customer in order to identify the
relationship maintained with him/her.
Primary Function File in CMS

Key
Customer This is the first record that is created for a new account. This contains the AMNA
Number customer’s demographic information such as name, address, telephone
number and place of employment. The customer number identifies the
particular name/address record.
Relationship The relationship record contains the information about all accounts AMRM
Number associated with a customer. The Relationship number is used to identify
the customer as a portfolio of all the credit products held by him/her at
any point of time.
For e.g., if the customer has a credit card as well as a home loan with the
same organization, he/she will posses only one relationship number that
identifies him/her across the entire portfolio. This allows the organization
to take decisions with respect to credit limits and the type of products it
might offer him in future and based on the customer’s behavior pattern.
Account Each product held by the customer is called an account (e.g. Gold Credit AMBS +
Number Card, Silver Credit Card, Home Loan, Personal Loan etc). An account AMPS
number is used to identify the credit product held by the customer. In
other words, it is the identification of an entity, which holds all the AMBS is the
financial transactions of a customer for one particular credit product. Base Segment
Information regarding the account is stored in the file called the Base
Segment.
Card For every credit card account, there can be multiple cards issued to the AMED
Number customer (generally in the case of Primary & Secondary cardholders for
private cards or in the case of Corporate cards). A Card Number that is
unique to each card is printed on the credit card. A Primary card is given
to the cardholder who has the financial responsibility. The Secondary
cards are given to the dependants of the primary cardholder.
Information regarding each card is held in the respective Embosser files.

These Embosser files are attached to the single Base Segment file to
which they belong.
17
Account / Card Number Details
Every account / card number is a 16 digit number.
 The first six digits are the BIN numbers provided by Visa / Mastercard
 Digits 7-9 are the logo number i.e. they identify the product.
 The 10th digit is a variable identifying whether it is an account number
or a card number.
 Digits 11-15 are randomly generated by the system.
 The 16th digit is a Mod Check Number.
Given below is the diagrammatic representation of how the account structure looks for a
privately held credit card with a primary cardholder and two secondary cardholders:
Private Card (One Primary Card Holder and 2 Secondary card holders)
Relationship Record
For Vikas
Base Segment 1 Base Segment 2

Account: Gold Credit Card Account: Home Loan
Embosser 1 Embosser 2 Embosser 3

Primary: Vikas Secondary: Ravi Secondary: Lata
Customer Info 1 Customer Info 2 Customer Info 3

Vikas Ravi Lata
In the above example, Vikas is the Primary Cardholder. Ravi and Lata are Secondary
Cardholders. The details of Vikas are held at a common place in order to be accessible to
both the credit products held by him, viz., the credit card and the home loan.
This the relationship record further signifies that all the details of Vikas will be held in
order to keep track of the various credit products the customer has in his portfolio.
Issue Processing
Once the credit card account is created, the following 3 files are then created in the CMS
module in order to store card specific information.
18
1. Embossing File: This is the information required for printing the plastic.
2. Card Mailer: This is the information required for mailing the plastic.
3. Pin Mailer: This is the information required for using the plastic.
1. Embossing File: This file contains the following information:
Front of the card
Name to be Printed Member Since Expiry Date Card Number
Back of the Card
On the Magnetic Strip
Name Card Number Expiry Date Service Code

CVV1 / CVC1* (3 digit number)
Outside of the Magnetic Strip
CVV2 / CVC2 (3 digit number embossed on the signature panel)
CVV1 (Card Verification Value 1) is used by the Issuing bank to check the authenticity of
the card using which the transaction has been made. CVVI is a function of Card Number,
Expiry Date and the Service Code. CVV2 is also a function of these three fields,
however, it is a different number. It is mostly used for Voice Authorizations.
To capture and transmit information needed for the authorization of the card, POS (Point
of Sale) / EDC (Electronic Data Capture) machines installed at the Merchant stores are
used. POS machines transmit only the authorization information present on the Magnetic
Strip while the EDC machines can be used for transmitting other information also. EDC
is a more sophisticated POS machine that allows the merchant to send additional data
like transaction details as well. However, in case the POS/EDC terminals are not
working, then the merchant can read out the field CVV2 over the phone for
authorization.
When a card is swiped on a merchant terminal, the following four fields are transmitted
to the acquiring bank’s systems.
Expiry Date Card Number Service Code CVVI
*CVV is used in case of VISA cards and stands for Card Verification Value.
CVC is used in case of MasterCard and stands for Card Verification Code.
19
Merchant Visa / MC
POS / EDC Acquirer N/w Issuer
Terminal
Transmits the If the Card Details Decrypts the Decrypts the

fields Card are of a card, information information using
Number, Expiry which it has not using the the IWK and then
date, Service issued, it encrypts AWK and verifies CVV1
Code and CVV1. the information then encrypts using CVK and the
using AWK and using IWK Card Number,
transmits the and transmits Service Code and
information to the to Issuer. Expiry Date.
network.
These fields are transmitted by the merchant terminal to the Acquiring Bank’s system,
which in turn encrypts using the Acquiring Working Key (AWK) and then transmits it to
the Visa/MasterCard Authorization network in case the Issuer of the card is some other
bank.
The Visa/MasterCard network in turn decrypts the information using the AWK, encrypts
the information using the Issuer Working Key (IWK) and then retransmits the
information to the Issuing Bank. When the Issuer receives the information, it decrypts the
information using the IWK.
The Issuer has a standard Card Verification Key (CVK), which is used for the
verification of the CVV1 values of all cards it issues. The CVK is used in conjunction
with the fields Expiry Date, Service Code and Card Number (received over the network)
to generate the CVV1. This is then compared with the CVV1 value received over the
network. If a match is found, a positive authorization is made, else the authorization is
declined.
2. Card Mailer: This file contains information like the Customer’s mailing address,
phone number etc. that can be used to mail the card and the pin to him/her.
3. PIN mailer: This file contains the PIN that helps the customer activate the card and
also use it later for cash transactions at ATMs.
The PIN that is sent to the customer in order to use his/her credit card is a function of
the card number, length of the PIN, card number length, expiry date, and a random
key.
20
Card Activation
Once the customer receives the card as well as the PIN, he/she can get is activated in the
following ways:
 Call the Customer Service Representative who activates the card
 Take a cash advance on the card. This automatically activates the card since he
needs the PIN to make a cash transaction and the PIN is sent to the cardholder in
a separate mailer.
The customer can then carry out other transactions on his/her credit card.
21
Authorizations
The process of verification of the authenticity of the card using the details received over
the network when the card is swiped, and the credit limit of the card is called
Authorization. In VisionPLUS, the module used for this is Financial Authorization
System (FAS).
There are 2 types of Card usage possible:
1. Cash Advances: Authorizations done at ATMs, and at Merchant Sites when using
Cash Access facility.
2. Purchases: Authorizations possible Via EDC/POS terminals, over Voice networks,
over the Internet and Manual Authorization possible.
In case of VISA, the authorization network used is called Base 1 while the network used
for MasterCard is called INAS. Incase of Private Label Credit Cards, local networks are
used.
Approval
ISO 8583 is the international standard used for transmitting data required for
authorizations. FAS can receive information only in ISO 8583 format. If the incoming
information from the merchant POS/EDC terminals is not in the ISO 8583 format, then a
pre-processor is used by the Acquiring Bank to first convert the information into the ISO
format for use by the FAS system.
Issuer
Acquirer Systems Systems
Merchant Pre
POS / EDC Processor VisionPLUS Visa / MC
Terminal N/w
FAS Module
Output
Processor
Merchant terminal If the incoming information is not in ISO 8583, a pre-

transmits card processor is used for converting the format to ISO 8583 and
information to the then fed to the FAS module of VisionPLUS. If the FAS
Acquiring Bank using module recognizes the card as belonging to another bank,
the format specified the information is sent to the network.
by the Acquiring
Bank. This format Similarly, while sending approval information back to the
may or may not be merchant, an output processor converts the data back from
ISO 8583. ISO 8583 to the Acquirer’s format.
22
When card information is received by the Acquirer bank for authorization from the
merchant, there are 2 scenarios possible.
1. Scenario 1: The Acquirer’s FAS recognizes the card to belong to the Acquirer itself
using the BIN information on the Card Number i.e. the Acquirer is the Issuer also.
In this case, the Acquirer’s FAS does basic validation like Card Number, Expiry Date,
Status Check (not reported as a fraudulent or lost card), credit limit and velocity
checks (number of transactions previously received from this card during that day).
Having verified this information, it then checks for the CVV1 value and once
validated, it sends an approval response back to the merchant.
2. Scenario 2: The Acquirer’s FAS recognizes the card to belong to another bank i.e. the
Acquirer is not the Issuer of the card.
In this case, the FAS transmits the encrypted card information to the Visa/MasterCard
network, which in turn transmits it to the Issuing bank. The information is then
processed by the Issuer’s FAS module as described above.
There are occasions when the Issuer’s systems are down and the Issuer cannot authorize
any incoming requests from the network. There is a pre-specified duration within which
the Issuer system has to respond to the request from the network. If no response is
received within this duration i.e. the Issuer systems are down, the Visa/MasterCard
systems undertake what is called the ‘Stand In Processing (STIP)’ i.e. they perform
stand-in authorizations for the Issuer.
The stand in authorizations are performed on the basis on some pre-defined standard
checks like cross checking the card number against the ‘Exception File’ (the exception
file is a file of fraudulent/lost cards that the Issuer sends to the Visa/MasterCard network
on a daily basis), checking for expiry date etc.
After the Issuer systems come back up, all the authorization advises are sent by the Stand
in Processor to the Issuer.
Post Approval
Once the card validity has been established and approval response sent back, the system
needs to validate whether the transaction amount is within the available the credit limit of
the card at that point of time.
The available credit limit of a card at any point of time is called ‘Open to Buy (OTB)’. It
is calculated as follows:
Open to Buy = Total Credit Limit of Card + Overlimit % of Card –[Current Balance +
Memo Debits – Memo Credits]
23
Current Balance is the total amount of the authorized transactions for which settlements
have been made i.e. transaction chargeslips have been received by the Issuer from the
Acquirer.
Memo Debits are those total outstanding authorized transactions, which have not been
settled yet i.e. the Issuing bank has not yet received the transaction chargeslips from the
Acquirer.
Memo Credits are those outstanding reversals/chargebacks, which have not yet been
settled.
Whenever a transaction is approved after the validity of the card has been established and
the transaction amount is verified to be lower than the OTB, FAS does the following:
1. Update the Memo Debit / Memo Credit amount in the CMS module.
2. Update the Authorization Log file (in FAS itself) with the details of the transaction.
The daily transactions are recorded in FAS in the ‘Authorization Log’ till the end of the
day. At the end of the day, all transactions are moved to the CMS module to a file called
AMOA. This is because all settlements are made in CMS.
After the settlements (transaction chargeslips) are received, matching of the chargeslips
is done with the AMOA records and after a match is found, the record is deleted from
AMOA. The Memo Debit is reduced and the Current Balance is increased.
Example: Vikas has received a new credit card with a Total Credit Limit of Rs 10,000.
He has not made any transactions on it. At this point of time his OTB is:
10000 (Total Credit Limit) + 1% (Overlimit %) - [0 (Current Balance) + 0 (Memo Debits) –0

(Memo Credits)] = 10,100
Now, Vikas makes a purchase of Rs 3,000 at a merchant store using his credit card. FAS
updates Vikas’ account for the Memo Debit amount on his credit card to 3000, since the
Acquirer has not yet made the settlement. After this, the OTB gets updated to:
10000 (Total Credit Limit) + 1% (Overlimit %) - [0 (Current Balance) + 3000 (Memo

Debits) – 0 (Memo Credits)] = 7,100.
After 2 days, when the Acquirer presents the transaction chargeslip to the Issuer, the Memo
Debit is reset to ‘0’ and the Current Balance is updated to ‘3000’. Hence the OTB remains
the same:
10000 (Total Credit Limit) + 1% (Overlimit %) - [3000 (Current Balance) + 0 (Memo

Debits) – 0 (Memo Credits)] = 7,100.
24
Transaction Routing
VisionPLUS is a Dual Messaging System i.e. the system/network that handles the
Authorization requests does not support the settlement requests. The Settlement requests
are sent via a different network. This network is called Base 2 for Visa and INET for
MasterCard.
Once an authorization for a transaction has been made, the merchant needs to send the
transaction details to the Acquiring Bank in order to the initiate ‘Settlement’. Settlement
is the process whereby the Acquiring Bank pays the merchant for the goods and services
delivered by him to the customer. Merchants generally send all transactions to their
Acquiring Bank’s system in batches, periodically (once a day or twice a week).
There can be several sources of transactions for the credit card transaction processing
system. Transactions can originate from retail merchant purchases, ATMs, internal fee
generation transactions etc. As such, the format in which these transactions are received
by the system can vary according to the source from it was received.
Similarly, the destination of each transaction can vary. Some may have to be routed to
different modules of the same system while others may have to be sent to different
systems altogether. Each destination system may have its format for accepting and
understanding information.
Hence there needs to be a module that helps understand the formats of the different
systems from where transactions have originated, identify the destination systems and the
route the transactions to the destination systems. This is taken care of by the module
called Transaction Management System (TRAMS) in VisionPLUS.
Issuer Systems
Acquirer Systems
TRAMS
Merchant TRAMS
Terminal / Visa / MC
ATM N/w
CMS MBS ITS

CMS MBS ITS
Transactions The Acquirer’s TRAMS module verifies When the Issuer’s TRAMS
originate from whether the transaction has originated from receives the transaction
either its card or someone else’s. If the transaction from the network, it
merchant belongs to its card, TRAMS routes it to the identifies the destination
stores or modules affected by the transaction. modules for the transaction
ATMs. and routes it to all the
Else the transaction is sent to the network. modules affected.
25
Working of TRAMS
There are 4 major steps involved in the working of this module. These are:
1. Input Processing: TRAMS uses a COBOL program called the Input FilePath to
recognize the formats and accept the incoming transactions from the different sources.
This program also helps in identifying the various destination points for the incoming
transactions. Transactions can be the source systems to TRAMS at multiple points of
time in a day.
2. Warehousing: TRAMS stores the transactions in a warehouse till the time it can send the
transactions to the various destinations in their processing windows. The system can also
warehouse all transactions received at various points of time during the day and release it
all at one time at night. Warehousing is done in AMWT file in CMS.
3. Reject/Suspend: Transactions that have failed due to an error can be warehoused for later
review and correction. Also, transactions that are correct but need review (transactions
causing the account to be overlimit) can be suspended for later action.
4. Output Processing: TRAMS uses a COBOL program called the Output FilePath to
create output files for transmission of the transactions to the various destinations in the
formats required by them. There can be upto 10 destinations for a transaction.
26
Transaction Posting
Once the transaction is routed to the appropriate destination from TRAMS, it needs to be
posted into the account in CMS to which it belongs. Transactions can either be generated
by the customer for e.g., purchases, cash advances etc, or can be system generated for
e.g., interest, late fees etc.
Transaction Posting Process:

While delivering a transaction to CMS, TRAMS generates and associates two fields with
it. One is the Transaction Code and the other is the Credit Plan.
Transaction Code Logic Module

Transaction
TRAMS
Credit Plan
Transaction Code
The Transaction Code specifies the type of the transaction. When the system is set up,
the transaction codes can be pre-defined by the user in order to differentiate between the
different kinds of transactions that are expected to be generated. Transaction Codes are
used primarily for statementing, reporting, and for determining the accounts in the
General Ledger (GL) to which the transaction needs to be posted. For e.g., Transaction
code 100 can be mapped to retail transactions.
The transaction code is used to map the transaction to the Logic Module in order to
update the relevant fields that constitute the total account balance (These fields are
explained in detail later). Based on the kind of transaction, the logic module helps in
identifying the fields that need to be updated. For e.g., principal balance, interest, fees
etc.
The various fields that can be updated with the help of the logic module are as follows:
 Principal Balance: This is the balance that comprises of all the transactions that
the customer has carried out
 Interest: This is the amount that is charged as interest for using the credit that is
expended on the credit card.
 Service fees: These are fees charged for providing the facility of cash advances
 Non-Sufficient Funds (NSF): Fees charged to the customer’s account due to the
bouncing of a cheque issued to pay an amount off the credit card
 Late fee: Fees charged on the account due to late payment on the credit card
 Over limit fee: Fee charged when the account balance goes beyond the prescribed
account limits
 Insurance: Amount charged as premium for insurance taken on the account
 Membership fees
All the above fields constitute the Total Account Balance for that particular credit product
held by the customer.
27
The key for any posting is hence the logic module. Once the transaction is routed, the
logic module defines which buckets/fields mentioned above need to updated in order to
reflect the transaction onto the account.
Credit Plan
Once the fields to be updated are identified, the group to which the transaction belongs to
needs to be determined using the Credit Plan identifier.
Credit plans are groups of transactions on which different pricing parameters can be
applied. The grouping is generally done based on the source of the transactions. For
example, the organization may want to charge a higher rate of interest on a cash
transaction done at an ATM as compared to a retail transaction. Similarly, a retail
transaction done at a store with which the bank has a tie-up may be charged a lower rate
of interest than the other retail transactions.
There can be multiple credit plans associated to an account based on the kind of
transactions it allows. These credit plans are attached to every account in the base
segment. For example the transactions could be broadly classified into 3 heads:
 Retail
 Cash
 Balance Transfers
Each credit plan segment is essentially predefined in CMS in the Credit Plan Master file
(AMCP) but TRAMS assigns every transaction with the respective credit plan identifier
to which the transaction belongs, since TRAMS recognizes the source of the transaction.
The Credit Plan is denoted by a 5-digit number. In VisionPLUS a business can maintain
up to 99,999 separate Credit Plan Segments. A Credit Plan Segment can be defined for
each transaction / purchase, based on the interest rates that are applicable for that
particular transaction as determined by the source at which the transaction has been
made. A customer can therefore have multiple Credit Plan Segments controlled by the
same Credit Plan Master File.
The AMCP template in CMS module is where the pricing terms are defined in the Credit
Plan Master File, which will be applicable to all the Credit Plan Segments defined under
that. The AMPS file is where the groups of data or the credit plans are stored for that
particular account.
Process Control Table

For every transaction that is user generated, there are other transactions that the system
triggers in order to complete the financial implications of that transaction. For example,
when a customer withdraws cash from an ATM using his credit card, the system needs to
trigger transactions to charge interest and a cash advance fees. The interest and fee
amounts that need to be charged, are stored in different tables.
28
The pointers to all these tables are stored in a central table called the Process Control
Table (PCT). Every account has a PCT ID stored in the Base Segment, which points to
the respective table ids to be used for the different charge types.
Process Control Table (PCT)

PCT ID Interest Table Insurance Table Fee Table Account Table
AA1 001 – 009 010 002 545
AA2 151 – 732 140 012 000
AA3 095 - 332 258 922 016
Note that each PCT ID can correspond to upto 12 interest table ids. The exact table id to be
used is determined by a field called the RTOI that is stored in the credit plan associated with
the transaction. This is because there can be different interest rates charged, for the same
account, based on the source of the transaction.
Let us take an example to further clarify the above concepts.
A typical account is structured in the following manner.
Fields in Account Balance

Credit Plan Principal Interest Fees Insurance
Retail at Shopper Stop
Retail at other shops
Cash Advance
Vikas holds a credit card with a credit limit of Rs. 10,000.
Transaction 1: Retail purchase of Rs. 1000

Transaction Code – 01  Logic Module – 11 (Principal)
Credit Plan – Retail

Credit Plan Principal Interest Fees
Retail 1,000
Cash
The logic module indicates the field that needs to be updated and the credit plan outlines the
group to which the transaction belongs. Hence, the total account balance at the moment is
Rs. 1,000, and the Open to Buy limit (i.e., the amount that is available for the customer to
use is Rs. 9,000).
Transaction 2: Cash Advance of Rs. 2000

Transaction Code – 02  Logic Module – 12 (Principal, Fees, Interest)
Credit Plan – Cash
29

Retail 1,000
Cash 2000
The cash advance taken by Vikas triggers another transaction for the cash advance fee to be
charged. In this case as well, Rs. 2,000 is updated in the Principal field under the Cash group
as indicated in the Credit Plan.
The fee to be charged for the cash advance is determined by the Process Control Table
(PCT). Let us assume that the PCT ID for the above example is AA1. The corresponding
figure for fee is 002.
Process Control Table (PCT)

PCT ID Interest Table Insurance Table Fee Table Account Table
AA1 001 – 009 010 002 545
AA2 151 – 732 140 012 000
AA3 095 - 332 258 922 016
The fee table is hence referred to in order to find out the fees applicable.
Fee Table
Table Fee
001 5%
002 6%
003 7%
Hence, in this case, the fee applicable is 6%.

Retail 1,000
Cash 2,000 120 (6% of 2,000)
The total account balance is now 1,000 + 2,000 + 120 = Rs. 3,120.
Apart from a fee that needs to charged on the account, interest needs to be posted onto
the account as well. Interest on Cash advances are charged right from the day the
transaction is made. The Credit Plan has the RTOI number (i.e. the Interest Rate Table
Number in the PCT. In this case let us assume that the RTOI code 03.
30
Account Base Process Control Table

Interest Table
PCT ID: AA1
PCT 01 02 03………...12 001 4.5%
002 5.5%
AA1 009 010 002 545 003 5.1%
AA2 013 140 012 000
BA1 199 258 922 016
Credit Plan
RTOI: 03
The Interest table is identified using the PCT ID and the Interest Rate Table number. In
the above example it is 002. From the interest table, the applicable interest rate is 5.5%.
The total account balance now looks like this.

Retail 1,000
Cash 2,000 110 (5.5% of 2,000) 120 (6% of 2,000)
The total account balance is hence, 1,000 + 2,000 + 110 + 120 = Rs. 3,230.
31
Statement Processing
This is the process of issuing the billing statement to the cardholder for the transactions
carried out by him during the statement period. The date of issuing the statement to the
cardholder depends on the Billing Cycle parameter set in the Base Segment for the
particular account. This is a 2-digit field, which can take values from 01 to 31. The value
set in this field indicates the date on which the statement will be generated by the system.
On a statement day, there are some standard functions that are performed. These include:
 Interest calculation: This involves calculating the interest that has accrued on the
account since the last statement.
 Payment computation: This consolidates the information from the individual
credit plans associated with the account, to generate the payment amount and
repayment schedule for the whole account.
 Insurance Premiums calculation: This involves calculating the premiums on the
various Insurance policies associated to the account. This also includes making
decisions on canceling insurance on delinquent accounts.
 Generating the Statement file: This involves generating the statement file and
sending to the output processor for further processing (printing, mailing etc).
There are several parameters, which govern the statement processing of an account.
These parameters are generally stored at the base segment level for that account. These
include:
 Block Codes: Block codes can be used to control the printing of statements. This
can involve printing statements normally, hold printing or print online only.
 Statement Flag: This flag is used to control the statement processing option.
 Option at the account level indicating if the statement should be printed if there
has been no activity during the statement period.
Statement Details
A typical statement communicated to the customer consists of the following major fields.
 Total Due: This is the total balance of all transactions made by the customer,
across the different credit plans, till the date of the statement generation for which
payments have not been made. This includes the Insurance premiums, Interest
fees and the late payment fees (if any) and the carried over balance from the last
statement period.
 Minimum Payment Due: This is the minimum payment that the customer needs
to make for the statement period in order to avoid becoming a delinquent account.
On the day of the statement, all the transactions carried out during the statement
period are consolidated and this value is calculated. There are several ways in
which this value can be calculated:
32
 A fixed percentage of the Total Due for the statement period.

 A fixed payment based on the repayment table value (the repayment table
lists down fixed minimum payment values based on Total Due ranges).
 Charge certain components like Interest, Insurance Premiums etc in full.
 Due Date: This is the date till which the customer needs to make the minimum
payment due, to avoid going into delinquency.
 Detailed Transactions: A detailed listing of the individual transactions in each credit

plan or a single consolidated amount for each credit plan is provided based on the
settings in the Credit Plan Master record for that credit plan.
Interest Processing
Each credit plan attached to an account refers to a different interest table for the
calculation and charging of interest on the transactions carried out for that credit plan.
This is because the way interest is calculated and charged on Cash transactions may be
different from the way it is done for Retail transactions. Similarly, the bank may charge
lower interest rates on transactions done at some retail shops as compared to the others.
The interest tables (ARMR) which are referred to for the interest calculations and
charging, specify the following information:
 Method of Interest Accrual: A code on the table determines whether the
interest should be accrued on a daily basis on the aggregate balance or
whether the interest should be calculated on the average daily balance
computed at the end of the month. Please refer to Appendix A for an
illustration of how interest is accrued daily and on a monthly basis.
 Charging of Interest: This code specifies whether the interest for that credit
plan segment should be accrued and charged in the current billing cycle itself
or whether it should be accrued but charging be deferred till after the Due
Date for the current cycle and in case the total balance is paid in full, the
interest be dropped completely. Please refer to Appendix B for an illustration
of the same.
33
Payment Processing
Once the transaction is posted onto the customer’s account and a monthly bill is
generated, the customer is given a due date by which he will have to make the payment
for the same. This is known as the Statement Due Date or the Payment Due Date. The
payment modes and the procedure used for processing these bill payments received by
the customers is covered in this section of the document.
Payment Modes
Customers can make payments towards their bills in the following three ways:
 Cash
 Cheque
 Direct Debit: Option exercised by the customer that allows the issuer to directly
deduct the bill amount from the customer’s bank account. The customer can
specify whether the entire bill amount or the minimum due amount needs to be
debited.
The direct debit option is controlled by the ACH flag status. If the flag shows a
‘Y’ status, it indicates that the direct debit option has been exercised.
There are three modes of communication between the Issuer and the bank with
which the customer holds an account.
 Positive Response: The Issuing bank’s system sends a request to the
account holding bank and expects a positive response if the balance in
the account is sufficient to cover the amount to be debited. Only after
a positive response is received, is the payment posted to the
customer’s account in the issuing bank’s system.
 Negative Response: The Issuing bank’s system sends a request to the
account holding bank and simultaneously warehouses the transaction
for ‘x’ days (as defined in the Issuing bank’s system) in a file called
AMWT. The Issuing bank expects a response from the account
holding bank only in cases where the balance in the account is
insufficient to cover the amount to be debited. If a negative response is
received within ‘x’ days, the warehoused transaction is dropped, else
the bill payment transaction is posted onto the customer’s account.
 No Response: In this case, the Issuing bank does not expect any
response from the account holding bank and directly posts the bill
payment transaction onto the customer’s account.
Payment Handling
Payments made by customers can be processed in two ways:
 Directed
The cardholder can choose individual Credit Plans towards which payments can
be made. It requires the customer to nominate or choose the plan segment he/she
wishes to pay. For e.g., payments made towards paying off deferred interest to
avoid further interest charges.
34
 Non Directed
The cardholder can make a Consolidated Payment to his account covering the
minimum due of all Credit Plans. In other words, the payment is allocated across
all plan segments according to the controls set in the Credit Plan Master.
For e.g., an account has the following Credit Plans and the customer has made a payment of Rs. 100.
Minimum Due
Credit Plan 20000 (Retail at Shoppers Stop) Rs. 55
Credit Plan 10000 (Cash) Rs. 20
Credit Plan 11200 (Retail at Lifestyle) Rs. 55
Total Rs. 130
Incase of a Directed Payment where the customer has requested for the payment to be
made towards paying off his retail purchase at Shoppers Stop first, and then Cash
followed by Retail at Lifestyle the payment processing would be done in the following
manner.
Minimum Due Payment made by

Customer
Credit Plan 20000 (Retail at Shoppers Stop) Rs. 55 Rs. 55
1
Credit Plan 10000 (Cash) Rs. 20 Rs. 20

2
Credit Plan 11200 (Retail at Lifestyle) Rs. 55 Rs. 25
3
Total Rs. 130 Rs. 100
Incase of a Non Directed Payment, the payment allocation is done in a system

determined manner. The parameters and the process involved have been mentioned
below.
Payment Allocation
Once the customer has made the payment, as discussed above, they can exercise a
discretion in terms of which outstanding amount they would like to settle first. Incase of
Non Directed payments various priorities and payment methods are checked before
processing the payment.
1. Plan Priority
Every Credit Plan Segment has a priority that determines the sequence in which it gets
paid. The Plan priority ranges from 01 (highest) to 99 (lowest). Let us take the example
given above.
35
Plan Minimum Payment made by

Priority Due Customer
Credit Plan 20000 (Retail at Shoppers Stop) 02 Rs. 55 Rs. 45
Credit Plan 10000 (Cash) 03 Rs. 20 Rs. 0
Credit Plan 11200 (Retail at Lifestyle) 01 Rs. 55 Rs. 55
The Credit Plan with the highest priority (which is 01 in this case) gets paid first, the plan
with the next priority (02 in this case) gets paid second and the plan with the lowest
priority (03 in this case) gets paid last.
2. Plan Payment Control/Plan Payment Option

Determines how plans of equal priority can be treated. E.g., In case of FIFO (First In
First Out), the oldest plan will be treated first. In case of LIFO (Last In First Out), the
latest plan or the newest plan will be treated first.
For example,
Date of Plan Minimum Payment

Creation of Priority Due made by
Credit Plan Customer
Credit Plan 20000 (Retail at Shoppers 15 Nov ‘03 01 Rs. 55 Rs. 45
Stop)
Credit Plan 10000 (Cash) 18 Nov ‘03 02 Rs. 20 Rs. 0
Credit Plan 11200 (Retail at Lifestyle) 1 Nov ‘03 01 Rs. 55 Rs. 55
According to this example, Credit Plan 20000 and Credit Plan 11200 have the same Plan
Priority. Let us assume that the Plan Payment Control method used is FIFO. In which
case, Credit Plan 11200 will be paid first and Credit Plan 20000 will be paid later as the
former was created on 1 Nov ‘03, which is earlier than 15 Nov ’03.
3. Payment Hierarchy
Payment hierarchy determines the order in which the plan components are paid off. Plan
components comprise of various buckets such as Interest, Insurance, Fees, Capital etc.
These are also known as the BNP (Billed Not Paid) components. The allocation of
payments to the components that make up the current balance are done by entering a
number from 01–11 for each component. The system first pays the component designated
as 01, then pays component 02, and so on, until the system reaches 11 or depletes the
payment amount.
The current balance of a credit plan consists of the following components:
 Principal balance
 Interest BNP
 Service charges BNP
36
 Late charges BNP

 Insurance BNP
 Miscellaneous fees BNP (NSF Fees)
 Over limit fees BNP
 Annual fees BNP
 Collection expenses BNP
 Recovery expenses BNP
 Current month purchases
In some cases, the same hierarchy number is entered for multiple components. The
payment is then distributed on a pro rata basis of the component value.
For e.g., assume that the same hierarchy number is used for both interest and
insurance. When applying a payment of Rs. 12.00 to a credit plan that has Interest
BNP of Rs. 100.00 and Insurance BNP of Rs. 50.00, the system prorates the
payment as Rs. 8.00 to Interest BNP and Rs. 4.00 to Insurance BNP (maintaining
a 2:1 ratio).
The following example indicates the payment hierarchy methodology.
Date of Plan Payment Hierarchy

Creation Priority
of Credit
Plan
BNP Buckets Interest Insurance Fees
Credit Plan 20000 (Retail at 15 Nov ‘03 01 1 3 2
Shoppers Stop)
Credit Plan 10000 (Cash) 18 Nov ‘03 02 1 3 2
Lifestyle)
In the table shown above, the priority of the BNP components is Interest, Fees and
Insurance respectively. This indicates that any payment made towards the credit plans
have to follow the payment hierarchy in terms of which BNP bucket it will clear first.
Payment Hierarchy has to be applied in tandem with Payment Application method. This
is explained in detail in the following section below.
4. Payment Application Method

Application methods control how payments are applied across the various buckets across
the plans. The payment method determines to a large extent which BNP component
needs to be paid and when. Hence, the allocation of the payment received from the
customer is determined by the parameters that are set.
37
Example 1: When the Payment Application method specifies that the BNP buckets will
be paid in the order of their priority across all plan segments.
Date of Plan
Creation of Priority Payment Hierarchy
Credit Plan
2 8 5
Shoppers Stop)
3 9 6
1 7 4
Lifestyle)
In the above table, interest will be paid first across all credit plans based on the plan
priority and plan control method. The order of payment is indicated in the numbered
boxes.
Example 2: When the Payment Application method specifies that the BNP buckets will
be cleared for a single plan first based on its plan priority. In this case, the payment will
be made as follows.
Date of Plan
Creation of Priority Payment Hierarchy
Credit Plan
Credit Plan 20000 (Retail) 15 Nov ‘03 01 1 3 2
4 6 5
7 9 8
1 3 2
38
Delinquency
When a cardholder fails to make a qualifying payment within the stipulated period for
the first time, the account becomes a Delinquent account. The qualifying payment is
generally set slightly lower than the ‘Minimum Payment Due’ and the stipulated period
may either be set in the system (ARML) as the ‘Due Date’ or the ‘Statement Date’.
If the account is already delinquent and the cardholder misses the qualifying payment
again for the current cycle, the account is said to Age.
Similarly, when a delinquent cardholder makes the qualifying payment for the current
cycle, the account is said to Re-age.
Cycle Due and Delinquency Bucket

The Cycle Due value stored in ARIH indicates the number of cycles for which an amount
is due. This value is an indicator of the customer’s ability to repay. The total account
distribution of the bank by the Cycle Due value is a reflection of the portfolio health of
the bank.
The following table indicates the various cycle codes associated with the various
delinquency buckets.
Description Nothing Current 0-29 30-59 60-89 90-119 120-149 150-179 180+
(‘x’ days) Due Due
Cycle 0 1 2 3 4 5 6 7 8
Codes
Example: The Statement Date for Vikas is the 1st of March. The Minimum
Payment Due for Vikas is Rs 200 and the Due Date is 20th of March.
From the 1st till the 20th, the account is in the Current Due state, while on the 21st,
if the minimum payment has not been made, the account is transferred to the 0-29
bucket and the Cycle Due value is set to ‘2’.
On the next due date, i.e. 20th of April, if the payment has still not been received,
the amount is transferred to the 30-59 bucket and the Cycle Due value is set to
‘3’.
There are 2 types of delinquencies that are generally tracked by most systems:
Contractual Delinquency: The Cycle Due code is also called Contractual Delinquency,
which is defined as the number of billing cycles for which an amount is due.
Arriving at the Contractual Delinquency of an account in VisionPLUS involves setting

the Payment Variance amount. The Payment Variance amount is the maximum amount or
39
percentage by which the payment can full short of the Minimum Payment Due and still
not result in the aging of the account. The value is set at the account level.
Example: If the Payment Variance has been set to 10%, and the minimum
payment due is 200, then even if Vikas makes a payment of Rs. 180, then the
account is not aged.
Recency Delinquency: This is defined as the number of billing cycles that have passed
since the last qualifying payment was posted to the account. Qualifying payment follows
a similar concept as Payment Variance of Contractual Delinquency.
Re-aging: This is the process where the delinquency of the account is adjusted in a way
that the account becomes less delinquent, as and when payments are received from the
account holder towards his outstanding balance.
Illustration to explain Contractual Delinquency and Recency Delinquency
Vikas has an account for which the statement date is the 1 st of every month and the
Payment Due Date is the statement date of the next month. The payment variance is
90%. He makes some transactions in December for a total of Rs 1000.
 On the 1st of Jan, a statement is generated for his account in which the balance is
1000 and the minimum payment due is Rs. 100. So, on the 1 st the delinquency table looks
likes this:
Jan 1 Feb 1 Mar 1 Apr 1 May 1
Current Due 100
0-29 (2)
30-59 (3)
60-89 (4)
90-119 (5)
120-149 (6)
 Vikas does not make any payment in Jan and has not made any new transactions.
This causes the Rs. 100 from Jan to move to the 0-29 bucket. Also, on 1 st Feb, another
Rs. 100 from the January bill of 1000 gets added to the Current Due bucket.
Current 100 100
0-29 (2) 100
30-59 (3)
60-89 (4)
90-119 (5)
120-149 (6)
40
 On the 1st of March, a new statement is generated. There have been no new transactions in Feb and
no payment received yet. The account now looks like this:
Current 100 100 100
0-29 (2) 100 100
30-59 (3) 100
60-89 (4)
90-119 (5)
120-149 (6)
The Cycle Due (Contractual Delinquency) at this stage is 3 and Recency Delinquency is
2 as qualified payments have not been made for 2 cycles.
 Vikas makes a payment of Rs. 150 by the 10th of March. This causes his Contractual
Delinquency to re-age. Rs 100 is taken off from his last bucket and Rs 50 from the
bucket prior to that. This is what is account look like on the 10h of March:

Current 100
0-29 (2) 50
30-59 (3)
60-89 (4)
90-119 (5)
120-149 (6)
The Contractual Delinquency is now down to 2 from 3 and the Recency Delinquency is
0.
41
Collections
Once accounts become delinquent, they have to be sent to the collections department for
follow up with the customers. The collections aspect of credit card processing is handled
in VisionPLUS by the module called ‘CTA’ (Collections Tracking and Analysis). CTA is
a parameter and classification controlled system and allows priority based queuing of
accounts for follow up and reporting. CTA interfaces with the CMS modules to receive
and process delinquent accounts.
Accounts in CMS are examined on a daily basis for certain collection conditions.
Currently, nine reasons for CMS exist which send accounts to collections. Once an
account meets any one of these criteria, CMS flags the account during the daily run,
writes a tag record, and sends the account to CTA. There are priorities assigned to these
reasons and if an account meets more than one condition for collections, then the reason
assigned to that is the one with the higher priority.
The 9 CTA reasons are as follows:
1. First Payment Default: A new account was billed for the first time and the due
date was reached without a payment being posted to that account.
2. Over Credit Limit: Two fields are defined for this condition. The first field
specifies the overlimit percentage established for accounts in the base system,
while the second field specifies the percentage an account must be over its
credit limit before it will be sent to CTA. In some cases, both these fields can
have the same percentage.
3. Excessive Usage: This condition is controlled by two fields. In CMS, these
fields are Daily Excess Use and Cycle Excess Use. The first field indicates the
daily excess use; that is, the maximum number of times that the customer can
use the card on a given day. The second field indicates the maximum number
of times that the customer can use the card during the cycle. If either limit is
exceeded, the account is flagged for monitoring.
4. Delinquency: This condition indicates that the account is delinquent and
specifies the number of days or cycles the account must have been delinquent,
as well as the minimum balance necessary to move the account to CTA.
5. High Priority Block Code: Accounts with specific block codes can be sent to
CTA. Accounts with high priority block codes override any other reason for
collections except charge-off.
6. Recency: The condition of recency exists when the account surpasses a user-
defined number of billing cycles without having made a qualifying payment.
7. Low Priority Block Code: Accounts with specific block codes can be sent to
CTA. Accounts with low priority block codes are overridden by any other
reasons for collections.
8. Charge-off: This indicates the account has completed the initial charge-off
process and has a charge-off status of “5” (Automatic) or “6” (Manual).
9. Delinquent and Overlimit: This indicates the account is both delinquent and
overlimit.
42
CTA Process Flow
CMS Criteria 004 Criteria 007 Criteria 103

Exception
Tagged
Priority: 005 Priority: 010 Priority: 050 Report
Accounts
Class: 500 Class: 501 Class: 502
Class 500
Class 501 Class 502
Collector 1 Collector 2 Collector 3 Collector 4 Collector 5 Collector 6
Once an account is ‘tagged’ (marked) for collections, it is written to the ‘Collection Tag
File’. This file is then read by CTA and passed through the various criteria records it has
stored.
Criteria Records: CTA can have upto 998 criteria records for each organization
that is defined in it. A criteria record is nothing but a grouping of various
parameters with various value ranges assigned to each parameter.
The accounts received in the tag file are compared to each criteria record
individually and if the account characteristics tally with the parameter ranges
assigned to the particular criteria record, then it is sent to the particular
classification file assigned to that criteria record. There is a sequence number or
priority assigned to each criteria record and all accounts present in the Tag file are
compared to the criteria records according to the sequence number of the criteria
records. The closer the sequence is to zero, the sooner the record is examined.
For example, a typical criteria record listing would be as follows:
Criteria Priority Class Reason Pin Code Account Phone

Code Range Balance
004 005 500 Delinquency 500000- 10000- y
500010 30000
007 010 501 Recency 500011 30000- n
500020 50000
103 050 502 Recency 500011 30000- y
500020 50000
Vikas’s account in the tag file has the following details.
43
Reason Code: Recency

Address Pin Code: 500012
Account Balance: 35,000
Phone: Yes
The account is first compared to the criteria record 004 (as per the priorities) and
when the match is not found, it goes to 007. When a match is not found here too,
it goes to the record with the next priority i.e. 103. Here a match is found. Hence
the account is sent to the Classification file 502.
The following table illustrates the manner in which the matching is done against
the various criteria records.
Criteria Priority Class Reason Pin Code Account Phone

Code Range Balance
004 005 500 Delinquency
 500000-
 10000-
 y

500010 30000
007 010 501 Recency 500011 30000- 
n

500020 50000
103 050 502 Recency 500011 30000- y
 500020
 
50000

If an account does not match the parameters set in any of the criteria records, it is
placed in an Exception File.
Classifications: Classifications define the individual collection strategies that

will be employed on accounts belonging to that classification. Each classification
is identified by a 3 digit code. Each classification contains information on
collector assignment parameters required for queuing the accounts to the
collectors who have been assigned to that classification. Apart from this, valid
action codes that collectors can use on accounts are also included in each
classification.
Every incoming account, is assigned a priority based on the classification and the
account balance. These priorities determine the order in which these accounts will
be worked on during the day. Priority codes are established on the Classification
record and can have a value of 0 to 9, with 0 as the highest priority. Within the
class priority are account balance priorities from 01 to 98, with 01 designated as
the highest priority.
Collector Queue: Once the collectors are identified based on the classifications
for the individual accounts, the accounts are lined up in the individual collectors’
queues based on the priorities assigned to them. The priorities determine the order
in which the collectors have to work on the accounts.
44
The collector needs to update an account with a valid action code (one that is
defined in the classification from where the account originated) to be able to
move to the next account in the queue. Each action code (e.g. Busy, No Answer,
Promise to Pay etc.) has its own processing rules that are defined in the system
e.g. If it is a Promise to Pay action, then the Amount and Date have to be entered.
If on that date the amount is not paid by the customer, then the account queues up
again.
Collector Statistics: There are several ways in which the collector’s performance
can be monitored in CTA. It allows the manager the flexibility of specifying the
parameters on which the performance will be measured. For example, the
performance can be measured by the number of accounts that were successfully
collected, aged-up, aged-down or maintained in status quo by the collectors, or by
the total balance collected by the collectors for that cycle, or by the total number
of positive actions taken in terms of resolving the delinquency.
Collection Agencies: The organization may outsource its most delinquent

accounts to collection agencies for follow up. CTA allows the collection agencies
to be setup as collectors and the same set of processing rules can be used for the
agency to track the accounts assigned to it.
45
Charge Offs
An account is charged off when the cardholder cannot repay his account and the
organization writes the amount off in its books as a bad debt.
Within VisionPLUS, in the CMS module, there are several stages that an account goes
through during the charge off process. The following status codes are used in CMS:
0 = Not Charged Off 4 = Blocked

1 = Potential 5 = Completed Automatically
2 = Pending 6 = Completed Manually
3 = Manual 9 = Account Abandoned
Status codes 1–3 are used for charge-offs in progress; 5–6 for charge-offs completed.
Accounts can be charged off either automatically (based on pre-defined levels of
contractual delinquency) or manually.
There are 3 major stages in an account’s charge off cycle:
 Pending Charge Off

 Initial Charge Off
 Final Charge Off
Pending Chargeoff
When an account is charged off in the system either manually or automatically, the
following are the conditions that are applied to it:
 Principal, interest, and fees billed-not-paid are kept separate when the account
enters charge-off.
 The system allows interest to accrue and fees to be assessed after charge-off.
 Any interest accrued and interest and fees billed-not-paid prior to charge-off
displays on the plan as an amount charged-off for each billed-not-paid component
at the time of charge-off.
 The system allows any transactions to post to an account that is in charge-off
status, subject to block code logic.
 A different payment application hierarchy can be applied to charged-off accounts.
 Accounts with credit balances will not go to initial charge-off, but an account that
is charged-off can have a credit balance. However, accounts with a credit balance
cannot go to final charge-off.
 A new method for beginning the pending charge-off process is initiated by
entering a charge-off reason code on an account.
 Credit Bureau reporting is automated when an account satisfies charge-off.
 An option to produce hard copy statements is provided.
46
 Certain fields determine when an account enters pending status automatically as

well as options for an account to charge-off automatically on a specific day of the
month or week, cycle date, or month-end.
Initial Chargeoff
The following are some of the changes that happen on an account the day it becomes an
initial charge off account:
 Charge-off status changes from 2 to 5 or 3 to 6

 Credit limit is zeroed
 Insurance is canceled
 Card Usage on ARIH is set to 4 (account is closed or charged off)
 Date on which the account is charged off is updated
 Interest is billed if the charge-off is on the cycle date else it is waived off.
 Set default charge-off reason and block codes from the logo.
 Print on the Charged Off Accounts Report
 Charge-off transaction is generated
 Transfer individual billed-not-paid components for each plan from accounts
receivable to profit and loss section
Once the above changes occur, the following results:

 No hard copy statements are produced
 No finance charges are assessed
 No payments are billed
 No delinquency aging occurs
 Existing current/past due buckets are frozen.
Final Chargeoff
Changes that occur on the day an account balance becomes final charge off include:
 Charge-off status changes from 5 or 6 to 9

 Internal status changes to “To be purged”.
 Prints on D09 (Charged-Off Accounts Report)
 The system zeros account balance
 Balance is removed from the profit and loss section.
47
ChargeBack Processing
When a cardholder disputes a transaction billed against him, the Issuer takes it up with
the Acquirer who reported the transaction to the Issuer, through a process called
Chargeback. The issuer returns the disputed transaction to the Acquirer with the
expectation that the Acquirer will return the payment made by the Issuer to the Acquirer
earlier for that transaction.
The following diagram indicates the main steps involved in a typical chargeback process:
Retrieval / Copy Request
Retrieval / Copy Response (Presentment)
First Chargeback
Re-presentment
Second Chargeback (Arbitration Chargeback)
Issuer Acquirer
Pre-Arbitration Letter
Response to Pre-Arbitration Letter
Arbitration
Cardholder Letter sent by fax
Chargeslip sent by fax
 The Issuer sends a retrieval / copy request to the Acquirer for the transaction that was
sent to it by the Acquirer and which it paid for. The retrieval request is basically a
request for the physical chargeslip of the transaction and is done for all transactions.
 The Acquirer responds by sending the chargeslip to the Issuer. If the Acquirer does
not respond within a pre-specified time, the Issuer can initiate chargeback.
 When a customer disputes a transaction, the Issuer initiates the 1 st Chargeback to the
Acquirer. The Issuer has to assign a reason code (Unauthorized transaction, different
transaction amount, duplicate transaction etc) to the 1 st Chargeback and sends the
cardholder letter as supporting documentation.
48
 The Acquirer, in an attempt to correct the problem, responds to the Issuer’s 1st
chargeback with additional documentation and information. This is called re-
presentment.
 If the Issuer decides that the presented information is still not sufficient, then it can
invoke the 2nd Chargeback (also called Arbitration Chargeback) process. This cycle
ends the system backed chargeback process.
 After this point the Acquirer and the Issuer can complete the pre-arbitration
formalities and take the matter for arbitration to VISA/Mastercard. This is generally
avoided, as the fee charged by VISA/Mastercard is very high for each transaction that
they arbitrate on.
Chargeback processing is taken care of in VisionPLUS by the Interchange Tracking

System (ITS) module. The major emphasis of ITS processing is the handling of
chargebacks and representments.
It interfaces with the CMS and TRAMS modules. CMS being the accounts receivables
system holds account information and also receives all original presentments for the
transactions made. This information is transferred to ITS to make copy requests, perform
chargebacks etc. TRAMS being the front end transaction posting system, receives the
incoming interchange transactions and routes them to and from ITS.
Transaction Processing by ITS

Transactions which are identified as ones that will be required to be sent to ITS for
processing, are tagged for inclusion in ITS, by CMS and TRAMS. These transactions are
posted to the ITS master files and are subsequently presented in the ITS Representative
Work Queues for further processing and action.
CMS
ITS
ITS Master
Representative
File
Queue
TRAMS
When a transaction gets tagged for inclusion in CTS, it is assigned a category based on
Account Type, Card Type, Cycle, Origin, Currency Code, Transaction Code, and Reason
Code. Each category is assigned a priority and within each category, each transaction is
further assigned a priority based on Pending days, Dollar Amount, and Reason Code.
These two priorities together determine the order in which the transactions will be
worked on in ITS.
ITS routes all out-going transactions to TRAMS, which then sends it to the network.
49
Customer Service
When customers call up the customer service centers of their respective credit card
issuing banks, they are assisted by the Customer Service Representatives (CSR) of the
bank. These CSRs inturn access the customer records via an online system and provide
the necessary support to the customers.
In VisionPLUS, all customer account information is stored and maintained in the CMS
module. However, for ease of use by the CSRs, a front-end system for CMS has been
developed. This is called the Account Services Management (ASM) module. This is
used by the CSRs to access account information and perform the required actions.
Representatives
Each of the CSRs is set up as a Representative on ASM and is assigned a 3 digit ID.
There are 4 levels of representatives’ possible in ASM (Level 1-4, with Level 1 being the
highest and Level 4 being the lowest) and each representative is assigned a level. These
levels control the kind of actions and the monetary value of transactions that can be
handled by the individual representatives.
Action Codes
When a customer calls up a representative and makes a request, the request is entered
into the system and the representative can work on the request using action codes. Action
Codes basically indicate the kind of action taken on the request made by the customer.
There are 6 types of Action Codes in ASM.
1. Monetary Action Codes: These are actions that change the financial status of
an account. Examples are finance charge rebates, corrections for wrongly
applied purchases etc. The security on these types of transactions are
controlled by:
 Representative ID / Level: There is a certain limit assigned with each
representative in terms of the maximum transaction monetary value
that he can process on his own, without any approval.
 Action Code: Certain action codes can be made available to only a few
select representatives.
2. Non Monetary Action Codes: These are actions that do not alter the financial
status of the account. Examples are Address Change requests, Re-Issue card
etc. Even here, Action Code level security to determine which representatives
can perform these types of actions.
3. Transcript Action Codes: These actions require gathering of additional
information before the action can be closed. For example a situation where a
customer disputes a transaction amount and the representative needing the
copy of the chargeslip before taking a final decision.
4. Inquiry Action Codes: These are straightforward inquiries from the customer.
Examples include inquiries on Current Balance or Credit Limit.
5. Point Action Codes: These actions are related to the frequent shopper points
gained by a customer.
50
6. System Generated Action Codes: This is related to system generated actions

like Letter request and Statement Reprint request.
When a representative receives a request, he can line it up in one of his 3 queues:
 Pending: This is the queue of all requests that the representative is working on.
 Transcript: This is the queue of all requests that the representative has put on hold
for want of more information.
 Referral: These are the requests that the representative has re-queued for other
representatives to work on. Representatives can queue requests to other
representatives based on their status on the system. Each representative needs to
logon to the system and can have any one of the following statuses:
 Active
 On a break
 At Lunch
 Signed Off
 On Vacation
Only representatives with the status ‘Active’ can be assigned actions.
Other Features
Some of the other features that are present in ASM are:
 Complete information on each representative, in terms of what he is/was

doing, logging in/logging out times etc, at any point of time is available.
 Representatives can message other representatives either individually or as a
group.
 An action history can be maintained on the accounts worked on by the
representatives. The last three actions taken on an account are always
displayed on the screen.
 Daily, weekly and monthly totals of actions taken by each representative are
available.
51
Customer Communication
At various points of time, the organization needs to communicate with the customer
using letters. This could be when the customer’s application is accepted and an account is
created for him, when his monthly statements have to be sent out, when reminders have
to be sent out for missed payments or when new promotions have to be announced.
VisionPLUS has a module called Letter System (LTS) that is designed to generate
letters through the use of online transaction screens and batch processing.
Multi-Application Access
The Letter System interfaces with other modules for various kinds of information used
within the generated letters. Modules that can be accessed include:
 CDM for account application letters
 CMS, ASM and CTA for established/existing account based letters
 MBS for merchant and store based letters
In addition to the five modules, the user may define access for up to five more user-
provided external application systems for other miscellaneous letters.
Letter Processing/Generation
A letter is added to the system by defining the letter parameters and writing the letter.
This needs to be set up before the letter can be requested. The application has the ability
to generate multiple page letters.
Letter Master
Letter Masters are templates that define the content of the letter that needs to be
generated. Once this is defined, only then can the letter be requested for. A
business can create up to 47,000 unique letters. The Letter Master:
 Contains static text and letter variables
 Up to 125 lines of text and variables are supported
 Possesses limited edit capability with respect to allowing lines to be
copied, moved, etc.
 Holds formatting information to be passed to the printing system. For e.g.,
upper case / lower case / sentence case
 Specifies the clearance code of the letter. For e.g., it prevents requestors
with insufficient authority to send specific letters
Letter Variables
Account information such as name and address are substituted with certain in
built variable codes. Letter Variables are codes that denote specific information
held on the data files in the various VisionPLUS modules. They are predefined in
LTS. For e.g., @CB006 = credit limit from CMS Base segment, @OC001 = name
of collector assigned to an account from CTA, @RR001 = name of
Representative from ASM, @SM021 = name of Merchant from MBS.
52
During the letter generation process, LTS extracts the account specific information from
the data files and replaces the variable codes with the actual account information that has
been retrieved.
Processing Sequence
The processing sequence outlines the various procedures that can be undertaken from the
request of the letter till the letter is finally printed awaiting postage to the customer. The
various steps involved are as follows:
Letter Request
Letter generation begins when a type of letter is chosen and any additional user-
defined variable information is entered. The letters can be requested
 Manually from LTS itself
 Manually and automatically from other VisionPLUS modules
 Manually and automatically from external systems
When the request is added to the system, it remains in the processing queue until
batch processing occurs. The letter also can be printed real-time/immediately
through an online printer.
Letter Deletion
Requests submitted for batch processing may be viewed online. The requests can
be deleted before printing if required.
Letter Expansion
The expanded letters can also be viewed online before being submitted. This
shows how a letter will look after variable codes have been substituted before it is
printed online or through batch processing.
Letter Maintenance
This function allows the user to move, copy, insert, and/or delete lines in the body
of the letter.
When processing occurs, the letter is sorted and printed according to the sequence
of the sort parameters defined for the letter in the Letter Master. The resulting file
of sorted, expanded letters can then be interfaced to an appropriate printing /
mailing system.
Online Directories
LTS comprises of various online directories that store information with regards to the
letter that needs to be generated.
 The Letter Variable Directory (LTDV) lists variables, their imbedded code
formats, and edit pictures (length and format of variable information)
 The Letter Directory (LTDL) contains a list of defined letters which includes a
code number and brief description of each letter
 The Organization Directory (LTDO) lists organizations and their LTS
identification numbers
 The Requestor Directory (LTDR) lists requestor’s sign-on, name, and location.
53
These directories have online screens that allow the users to view the information
required at any particular point in time.
54
System Security
There will be different users working on the VisionPLUS system for any system
implementation at any location. Given the sensitive nature of the information stored in
these systems, it is imperative to have different access privileges for different types of
users.
System security for the whole of the VisionPLUS product inclusive of all modules is
handled by a module called Security Subsystem (SS). It is a comprehensive online
system that interfaces between all the modules. SS is organized to allow a single
operator, called the Security Supervisor, to access all modules and the associated
functions. The SS oversees and controls access to all modules and establishes the sign-on
parameters for any number of Alternate Supervisors.
The Alternate Supervisors establish the parameters that define the extent of access other
users will have to the modules. Specifically, they can determine which modules a user is
authorized to access; which screens within the product a user is allowed to access; which
fields within those screens will be displayed; and whether the user can perform add,
inquiry, or maintenance functions. Security controls are established according to job
position and the level of security required for each position.
Some of the main features of this module are:
 Individual Field Regulation: SS allows restricting a user’s access to certain

fields on designated screens by specifying a Field Security table in the user’s
Security record.
 Multiple Security Levels: SS allows defining up to 17 different security levels
for each module. Each of the 17 security levels can be set up to allow access to all
functions for that application or to limit access to certain functions by grouping
them into separate security levels.
 Date and Time Stamp: Each add, inquiry, or maintenance function is date and
time stamped by user and terminal ID.
 Sign-On Expiration: SS allows setting of expiration dates for specific sign-ons
to accommodate temporary situations (e.g. temporary and contract employees).
 Specific or Multiple Terminal Access: SS allows restricting a user’s terminal
access to a single terminal, a range of terminals, or any terminal. Terminal access
is unique to each Security record.
55
Fraud Management
This is the process where organizations track card usage data in order to track possible
fraudulent use of the card. Interception of card details over the internet, using card reader
devices on POS/EDC terminals etc are ways that card details can be obtained
fraudulently and then used for carrying out transactions.
Most Fraud Management systems are post-authorization detection systems. Only the
approved and declined transactions are processed by them against the risk parameters.
Referred transactions, which are handled and verified by the Authorizers at the point of
referrals, are not processed by these systems.
VisionPLUS does not have any system/module exclusively for Fraud Management. Fraud
Management is an extremely sophisticated activity and is generally handled by
specialized systems in most organizations. VisionPLUS can be interfaced with a Fraud
Management system in order to provide information that helps prevent fraud. FALCON
is an example of a Fraud Management system.
There are two modes of processing in these systems: Online and Batch.
Online Processing: The online parameters are applied to authorization data. When
authorizations come into FAS, the entire data is passed onto the third party fraud
management system. The system uses a set of parameters on this authorization data in
order to flag accounts that appear suspicious. Some of these parameters used in online
processing are:
Abnormal hours Invalid CVV

Maximum Declines per day Exceeded PIN try
Maximum Amount per transaction Daily Count / Amount
Maximum Authorization per day X-days Count / Amount
POS entry mode Terminal / Merchant ID
Invalid Expiry Date
Batch Processing: Batch parameters are applied to settlement data. Settlement data is
received in VisionPLUS in the CMS module via the TRAMS module and then passed
onto the 3rd party system. This mode of processing allows the use of more historical and
comprehensive parameters on the data available. Also, there are some transactions that do
not require authorizations i.e. transactions below the floor limit of the merchant.
Information on such transactions can also be used for fraud management in batch
processing. Some of these parameters used in batch processing are:
POC Merchant
Collusive Merchant
Authorizations from different countries
No Approval Code
Late Presentment
56
Appendices
Appendix A: Interest Calculation Methods
"Interest
Calculation-Appendix A.xls"
Appendix B: Interest Accrual and Charging Illustration
"Interest Accrual and

Charging-Appendix B.xls"
57

Functionality and Operational Process of Credit Cards

Uploaded by

Copyright:

Available Formats

You might also like

Functionality and Operational Process of Credit Cards

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Functionality and Operational Process of Credit Cards

Uploaded by

Copyright:

Available Formats

Functionality and Operational Process of Credit Cards using VisionPLUS Level 2

Training Handbook for VisionPLUS

Functionality and Operational Process of Credit

OBJECTIVE OF THIS DOCUMENT................................................................................2

Objective of This Document

Overview Of The Credit Card Process

What are Credit Cards?

Types of Credit Cards

1. General Purpose Cards

2. Proprietary/Private label credit cards/Limited purpose cards

Credit Card Transaction Process

1. Customer: The user of the credit card.

2. Issuing Bank: The Issuing Bank maintains the customer relationship. It

4. Acquiring Bank: The Acquiring Bank maintains the merchant

5. Visa / MasterCard Associations: These are the associations that facilitate

As the Visa and MasterCard organizations gained prominence, most banks

Banks can become members of both Visa and MasterCard.

Credit Card Transaction Cycle

10. Provides goods and services.

3. Makes purchases using the card.

This authorization information is routed back to the merchant via the

How do different players make money?

Customer makes Acquirer deducts Issuer deducts Makes the payment

10000 – 400 -9600 + (10000-150) -9850 + 10000 -10000

Details of Players’ functions and economics

Advantages to Issuer Bank

Functions / Business Roles

Revenue side of Issuer economics

There are several alternatives that banks (Issuers) can adopt.

Thus some of the functions of the Issuer Processor could include:

Functions / Business Roles

 Outgoing interchange (processing outgoing sales drafts and cash

Revenue side of Acquirer economics

5. Credit Card Holder

 Credit cards make it easier for consumers to purchase goods, thus

7. VISA / MasterCard Associations

Business Roles/ Functions

Use Of VisionPLUS For The Credit Card Transaction Process

The Credit Decision Management (CDM) module in VisionPLUS handles Application

Processing Applications using CDM

 Setup: Approved applications can be set up as accounts in the CMS module.

CDM Field CMS file affected

Primary Function File in CMS

Information regarding each card is held in the respective Embosser files.

Account / Card Number Details

Every account / card number is a 16 digit number.

Base Segment 1 Base Segment 2

Embosser 1 Embosser 2 Embosser 3

Customer Info 1 Customer Info 2 Customer Info 3

1. Embossing File: This file contains the following information:

Front of the card

Name to be Printed Member Since Expiry Date Card Number

Back of the Card

On the Magnetic Strip

Name Card Number Expiry Date Service Code

Outside of the Magnetic Strip

CVV2 / CVC2 (3 digit number embossed on the signature panel)

Expiry Date Card Number Service Code CVVI