Credit Card Processing
Credit Card Processing
0
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
Table of Contents
1
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
Introduction
Credit Cards can be issued either by banks or other non-banking financial entities
and are generally associated with the Visa or MasterCard organizations.
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:
It also receives the transaction details from the Acquiring Bank and makes
the necessary authorizations for completing the transaction. It is also
3
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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.
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.
4
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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.
Customer Merchant
5
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
8
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
1. Issuer Bank
9
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
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.
10
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
11
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
6. Merchants
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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.
17
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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.
*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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
Merchant Visa / MC
POS / EDC Acquirer N/w Issuer
Terminal
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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).
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
22
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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:
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:
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:
24
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
28
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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.
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).
29
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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%
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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 is hence, 1,000 + 2,000 + 110 + 120 = Rs. 3,230.
31
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
Due Date: This is the date till which the customer needs to make the minimum
payment due, to avoid going into delinquency.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
For example,
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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).
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.
37
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
BNP Buckets Interest Insurance Fees
Credit Plan 20000 (Retail at 15 Nov ‘03 01 1 3 2
2 8 5
Shoppers Stop)
Credit Plan 10000 (Cash) 18 Nov ‘03 02 1 3 2
3 9 6
Credit Plan 11200 (Retail at 1 Nov ‘03 01 1 3 2
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
BNP Buckets Interest Insurance Fees
Credit Plan 20000 (Retail) 15 Nov ‘03 01 1 3 2
4 6 5
Credit Plan 10000 (Cash) 18 Nov ‘03 02 1 3 2
7 9 8
Credit Plan 11200 (Cash) 1 Nov ‘03 01 1 3 2
1 3 2
38
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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.
39
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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.
Jan 1 Feb 1 Mar 1 Apr 1 May 1
Current 100 100
0-29 (2) 100
30-59 (3)
60-89 (4)
90-119 (5)
120-149 (6)
40
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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:
Jan 1 Feb 1 Mar 1 Apr 1 May 1
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:
The Contractual Delinquency is now down to 2 from 3 and the Recency Delinquency is
0.
41
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
Class 500
Class 501 Class 502
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.
43
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
If an account does not match the parameters set in any of the criteria records, it is
placed in an Exception File.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
45
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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:
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.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
Final Chargeoff
Changes that occur on the day an account balance becomes final charge off include:
47
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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:
First Chargeback
Re-presentment
Issuer Acquirer
Pre-Arbitration Letter
Arbitration
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
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.
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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:
51
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
These directories have online screens that allow the users to view the information
required at any particular point in time.
54
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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.
55
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
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:
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
Functionality and Operational Process of Credit Cards using VisionPLUS Level 2
Appendices
"Interest
Calculation-Appendix A.xls"
57