Introduction to Rewards System

Let us take a look at Loyalty management system (LMS) popularly known as ‘Rewards’ system.

It is a system designed to allow card issuers to build a base of loyal customers by rewarding them with points or cash-back rebates according to their use of their card.

This is a VisionPLUS subsystem which presents a consistent look and feel as other VisionPLUS modules to maintain ease of use for operators and end users.

It is parameterized and enhanced (over CMS Frequent Shopper functionality) to provide maximum flexibility and tailoring from one loyalty scheme to another.

LMS System architecture:

LMS System Architecture

Online
Control Record (System, Organization & Scheme records) setup
Account setup, Name locate
Points Balance inquiries, Transaction History
Add/Maintain/Inquiry of Points transaction
CICS callable function to allow external access by third-party redemption systems
Batch
Non-monetary maintenance
Points calculation and posting
Expired points processing
Auto-disbursement
Reporting
Redemption Transaction file
Event Based non-monetary Transaction file.
Account Status

Interfaces
Accepts incoming monetary transactions from CMS(AR System)
Accepts incoming non-monetary user input to add and maintain master file data in the new Loyalty system
Accepts incoming non-monetary transactions files from a third party source to allow event based processing
Accepts incoming points transactions for Loyalty accounts from a Third party redemption system.
Creates outgoing General Ledger transactions
Creates outgoing Settlement file
Creates outgoing file of points that have been redeemed
Creates outgoing file of information to support the production of customer reward statements by CMS / Statement system
Provides a real time interface to a third party redemption system

What is Scheme?

A loyalty Scheme is required to attract the account volumes required to create a substantial and profitable portfolio.
The Loyalty Scheme will define the basic parameters regarding the earning, redemption and expiry of points.

What is scheme structure ?

An Account can be enrolled into multiple Schemes.
Loyalty Scheme Name field allows greater flexibility when setting up scheme (as it is five alphanumeric field).
All the accounts will have at least Default group.
Both type of groups can have three types of Plans – Base, Supplementary & Override.

Scheme Structure

What is a Group ?

There are 2 types of Groups in LMS:
The default group of all ‘A’s is defined for each Scheme and controls the basic earned points awarded to an account and settlement with the Provision Account.

• Default group Organization specific.
• Each Store is linked to Default Group (as a minimum) to generate Basic Earned Points.

Bonus Groups control the allocation of bonus points to an account and settlement with the merchant.

• Multiple Stores participating in a Bonus Rewards Scheme constitutes Bonus group.
• A Store can be associated with multiple Groups

What is a Plan ?

LMS defines three types of points for each Group attached to a Scheme:
Base points that are allocated to a loyalty account as part of the standard features and offerings of the loyalty program.
Supplementary points that are offered in addition to the base points for a specific promotion/period.
Override points that are offered instead of the base and supplementary points. This could be used to offer double points for the month of November each time the card is used.

Rate table & Rate Tiers:

Allows to determine and to vary the ratio of points assigned to a transaction at the points Scheme level based on the monetary value of the transaction.
Provides a facility to enter a minimum value that must be present to qualify for a point.
Bonus point definitions (Bonus Groups) have the option to define different rates.

Enrollment:

New accounts can be setup automatically from an external interface, such as CMS/ CDM/SNAP, or directly from within the Loyalty system using online transactions.
Possible to add new accounts on a daily basis through the Loyalty system batch process.

Enrollment

LMS can generate account numbers automatically.
In Automatic mode, record is added in Account cross reference file, LMS Demographic data file and Points account file.
In Manual Mode also LMS account no. can be generated automatically.
Manual Setup can be used for creating multiple LMS accounts for One AR account.
AR/LMS Account Cross reference file will have to be updated manually (QPAX).

Account maintenance:

Account details can be maintained either via an external interface, typically from CMS, or via online maintenance within the Loyalty system.

LMS automatically handles account transfers without the need for manual processes in Loyalty.

Account Maintenance

Adjustments:

Allows an operator to add, maintain or inquire upon batches of Point transactions.
The following types of transactions can be entered from these screens
Basic earned Points (debit or credit)
Bonus Points (debit or credit)
Redeemed Points (debit or credit)
Adjustment Points (debit or credit)
Manual Redemptions and redemption reversals.

Online transactions will be rejected online if
If the account is blocked or delinquent,
or for manual redemptions when the Open to redeem is less than the transaction amount he transaction will be rejected online.
Batch of ‘Adjustment Transactions’ is processed in the LMS batch.
If expired points need to be reinstated, the point’s adjustment transaction can be generated.

Redemption:

Redemption is the ability to allow a customer to redeem points. The points are redeemed in exchange for products or services
Oldest points will be redeemed first.
Accepts incoming file from a third party Redemption system
The block codes & Delinquency associated with the AR and or LMS account is checked before approval is given for redemption.

Redemption Process

Online Redemption thru LMS can be done using Points Adjustment Function.
For 3rd Party Redemption System, there is standard Record layout.
Auto Disbursement Frequency can be set to determine the time of disbursement.
An AUTO DISBURSEMENT METHOD parameter will allow the operator to specify the method of disbursement, Check, Credit or Certificate (Voucher).
Auto Disbursement Packet can be set. It is the number of points automatically disbursed, if the account’s available points balance is greater than or equal to this number of points. If the value is Zero then all points will be disbursed.

Provides the ability to define the number of days before points will become eligible for redemption after being received by the Loyalty system, using the warehouse facility.
Facility to determine whether the Cycle to Date points are to be included or excluded from the Open to Redeem Points calculations.
No matching off process will take place between outstanding redemptions and incoming redemptions. It will be the responsibility of the third party Redemption system to provide a file of realized redemption points to the new Loyalty system.

Settlement:

It is a financial settlement that occurs between the Loyalty points funding participant, Issuer, and the Redemption channel.
Merchant Settlement
Merchant settlement is the process whereby the Merchant is charged for participating in Loyalty Schemes. Merchants can be charged for Bonus points and can be charged at the group or store level.
LMS allows to define:
Merchants, both group and store level.
Merchant settlement accounts.
Rate charged. Expressed as a percentage.
Settlement methods available will be Direct Debit, Invoice or both

Redemption Settlement
Redemption settlement is the mechanism to pay Redemption
merchants for services received by the financial institution on behalf their cardholders throughout the selected redemption period.
LMS allows to define:
Redemption settlement accounts
Settlement with different redemption merchants at settlement intervals
Different dollar rates for redemption merchants.
Manual adjustment of redemptions for settlement purposes.

General Ledger:

For each points transaction processed, a monetary equivalent is calculated and then posted to the

General Ledger.
LMS allows to define :
General Ledger account numbers for debit and credit accounts for every monetary value processed by the system.
a percentage rate for the monetary equivalent value of a point and tax rates applicable.
Two sets of General Ledger entries are produced during LMS processing:
Provisioning :
Provisioning GL relates to the scheme owner putting money aside to cover the cost of points.
Merchant Settlement :
Merchant Settlement GL relates to requesting money from participating merchants for points awarded for customer transactions originated through the merchant.

Settlement General Ledger :
LMS will produce a single settlement GL file containing general ledger entries for merchant settlement for inclusion into the third party General Ledger System.

LMS allows to define :
Debit and Credit GL Accounts
Rate Percentage. The rate at which points are equated to a monetary value.

The provisioning General Ledger entries are system generated as a result of point’s calculation processes within LMS.

They represent monetary commitment for the points earned.

LMS allows to define :
Transaction code and description
Debit and Credit GL Accounts
Rate PCT
Tax Rate
for provisioning General Ledger

Transaction History:

Transaction History

Warehouse transactions – this screen will display all monetary transactions where the points are yet to be calculated and posted.

Active transactions – this screen will display the point transactions that have been calculated and posted but either the account has not statemented and/or the transactions have not been settled

Transactions history – this screen will display all point transactions that have posted, statemented on the loyalty account and settled with the merchant

Wildcard search feature (*) is allowed.

Transactions can be searched for on account number, Scheme, Merchant DBA, Merchant Id number, batch number, batch date or AR account number.

Period between Expiry of Points & Removal from the Transaction History file can be specified for a Scheme.

Card processing fees

Credit card processing companies, like other companies, must make a profit or go out of business. To achieve this goal, they charge fees.

These fees can be numerous. This can lead to some irritation. As in: What is all this stuff?

In the belief that knowledge is power, heres a quick breakdown of what all that stuff is.

Application Fee
Generally speaking, reputable companies do not charge this fee. They dont need to. They get enough business without charging up-front. Application fees are, by and large, bogus.

Startup Fee
Some work is involved in setting up a credit card processing account. A startup fee in the range of $25 can be justified, as long as the system thats set up works great.

Statement Fee
Credit card processing companies usually provide detailed statements at the end of each billing cycle. These statements show how many credit cards were processed, the times and dates of the swipes, good stuff. The organization of that information has value. So they charge for it.

A statement fee of seven to ten dollars per month is common.

Monthly Minimum
Credit card processing companies take a percentage of each transaction, so if no transactions are occurring, theyre not making any money. For this reason, they may put a andquot;monthly minimum not metandquot; charge into the contract. That way, they are assured of some revenue from each account.

Discount Rate
The discount rate is the primary fee charged by credit card processing companies. It is customarily between 1.5 and 2 percent of each transaction.

Charge Back Fee
Refunds complicate matters. If credit card transactions are repeatedly being charged back and forth, and the credit card processing company is being asked to void transactions after the fact, and so on, a charge back fee may occur.

Often, a certain number of charge backs are allowed per month before this fee kicks in.

Gateway Fee
This fee is related to the ability to process Internet credit card transactions. In order to do that, a credit card processing firm must provide some basic Web site services, such as a shopping cart function for the customer and/or a portal that lets the client accept and monitor payments.

A gateway fee in the neighborhood of ten dollars per month is common.

Termination Fee
Typical contract lengths are between one and three years, with early termination fees ranging from one to three hundred dollars. There are credit card processing providers who do not charge a termination fee. However, that may mean they charge a bit more in other areas.

How Much Is Too Much?
As a general rule of thumb, processing credit cards is a great deal if the cost is at or around two percent of total credit card purchases. If $100,000 of credit card purchases flow through a restaurant per month, processing credit cards might cost $2,000 per month.

When offers are flying around at less than that, be wary. Remember: credit card processing companies have to pay fees too, to the credit card companies themselves.

Without that two percent or so, credit card processing companies dont have a business.

Sources
Forbes

Primary and secondary level records in CMS

A collection of options and parameters which control the processing of the system, defined and maintained online, CMS consists of 25 control records.

▲Provide logical groupings based on Hierarchy of Business Controls

▲Primary Records

System levels control Processing Dates, system holidays and Interfaces.

Org level controls area of business, billing dates, ACH information, activity recap controls etc. Logo Level controls Account Processing Options like Payment options, account type etc.

▲Secondary records

Control the processing parameters like Interest rates, Insurance and account records

CMS has 22 secondary records which can be established as options under a controlling System, Organization or Logo record.

Example: Interest, Insurance, Fees, Account Parameter.

Block code matrix in CMS

CMS enables you to define up to 27 block codes (A–Z and space) on ARML07 and ARML08. Each block code can indicate special conditions and automatic processing activities that you can apply at the account level. You can apply up to two block codes to an account (BLK CODE 1 / 2 on ARMB01).

When you define the block codes for a logo, you assign a priority to each block code PRI on ARML07 and ARML08). Since you can apply two block codes to an account, the priority indicates to CMS, which assigned block code to activate first.

CMS enables you to define up to four letter codes for each block code (LTR 1 to TR 4 on ARML09 and ARML10). CMS sends the letter codes to CTA or LTS to generate the letters whenever a block code condition has been in effect for a specific number of days (DAY 1 to DAY 4 on ARML09 and ARML10). For example, CMS sends the letter code in LTR 1 when the block code has been in effect for the number of days in DAY 1. CMS sends the letter code in LTR 2 when the block code has been in effect for the number of days in DAY 2, and so on.

Credit Risk

The risk of loss of principal or loss of a financial reward stemming from a borrower’s failure to repay a loan or otherwise meet a contractual obligation. Credit risk arises whenever a borrower is expecting to use future cash flow to pay a current debt. Investors are compensated for assuming credit risk by way of interest payments from the borrower or issuer of a debt obligation.

Credit risk is closely tied to the potential return of an investment, the most notable being that the yields on bonds correlate strongly to their perceived credit risk.

The higher the perceived credit risk, the higher the rate of interest that investors will demand for lending their capital. Credit risks are calculated based on the borrowers’ overall ability to repay. This calculation includes the borrowers’ collateral assets, revenue-generating ability and taxing authority (such as for government and municipal bonds).

Credit risks are a vital component of fixed-income investing, which is why ratings agencies such as S&P, Moody’s and Fitch evaluate the credit risks of thousands of corporate issuers and municipalities on an ongoing basis.

Discussing Switching a bit

Switching is a centralized dedicated software system, which is overall controlling the different functionality which starting from capturing of data (messages) of the monetary transaction and non- monetary transaction through different channel and route it to the different entities.

• Capture and Route
• Capturing transaction and Routing to different entities (Authorizer).
• Examples of Switch – Electra, Open to Switch
• End to End processing
• Customer to Distribution

There are different phases in the Acquiring and Switching

1. Captures of the data through different channel.
2. Receive of the different message in a central Transaction Management entity.
3. Storage of all the messages in a central Database
4. Depending on the type of transaction; ON-US or NOT ON-US transaction routing to correct destination.

Depending on the Bank, a Switch can be an Acquiring Switch or Issuer Switch. If  the message capturing through different channel is excluded for the other phases like Transaction Management and Routing part,  the rest can be form the part of the Issuer switch.

Phase I

Capturing through different channel

Capturing monetary transaction in different channel

1. ATM

– henever an ATM is set for the first time/ there is change is accepting which all cards can be accepted, a down load file is being sent/ receives from the ATM and Switch.

Based on the type of the card, a OPCODE is being generated and as per that the screen are displayed; if it is a ON-US card then number of facility are provided to the card holder; other wise up to Authorization, only few functionality will be provided to the card holder.

– 1 OPCODE = 8 keys

– There is a one to one connection between the switch and ATM.

2. POS
   • Different POS are connected to the NAC (Network Access Control)
   • Data is sent from POS to NAC by means of (TPDU –Transaction Packet Data Unit)
   • POS uses the protocol Rs 232/x25
   • Example of the POS –Hyercom, Visacheck, Visa1

3. e-Merchant

-Merchant logon to the website through which he connect to the Web Server which in turn connect to the Payment Gateways – which again connect to the specific Interchange – again get connect the specific Acquirer id.

4. IVR
   • Mail Order Telephone Order –MOTO
   • Interactive Voice Recognition (IVR)
5. Local Networks

Phase II

Transaction Management ( Routing to different entities; based on the ON-US and NOT ON-US transaction)

Difference between the ON – Us and NOT ON –US

ON – Us	NOT ON –US
1. Check Card	Check Card
2. Check Card Expiry	PIN translate Security data
3. Check Stop list (Lost/Stolen)	Route
4. Check Security (PIN, CVV1, CVV2)	Process Response
5. Process Response

Phase III

Routing to different channel

• Bank Host
• VISA/MC
• Card Management System

Transaction Posting

Posting Overview

Monetary transactions that are not system-generated enter CMS in batches either through online functions or through user input tapes and transmissions.  Online sources of monetary batches include:

• The Monetary Batch Transactions screens (ARAT) or the Payment Transaction Entry screens (ARAP). ARAT accepts all types of transactions, including payments.  ARAP accepts only global payments (transactions linked to Logic Module 30).  These functions have maintenance modes (ARMT and ARMP) which allow you to modify batches.
• The Frequent Shopper Points entry screens (ARAH). Although points transactions do not affect account balances, they are treated as a sub-category of monetary transactions.
• The Account Services Management system (ASM). As customer service representatives enter Monetary and Points actions through the ASM Work screen (ASMW), the system automatically organizes them into batches that are later passed to CMS for posting.

When a transaction is presented for posting to a cardholder account, there can be one of three possible outcomes.  The transaction will be:

• Posted immediately in the day’s batch processing
• Non-posted (rejected)
• Warehoused for posting on a later processing day.

The particular action taken by CMS (post, reject, or warehouse) depends in large part on transaction posting parameters that you establish in the control records.

Batch Processing

A batch of transactions consists of a batch header record and the batch detail (contents).  The header record contains the batch number, the sum total of all transactions in the batch, and the debit and credit amounts that are included in the batch.  The contents are the records of the individual transactions.

• During batch processing, the system checks the contents of each batch against the batch’s header record.
• A completed batch is a batch that was properly closed at its source. An in-balance batch is one whose contents and header match.
• When a batch is both complete (closed) and in balance, the system takes one transaction at a time and attempts to post it.

 

 

Normal Posting

In most circumstances, there are five parts of a transaction record that must be present and correct for normal posting to occur:

• Account number
• Transaction code
• Amount of the transaction
• Credit plan number
• Store number.

An exception to this rule is a global payment on an account.  Because a global payment is not directed to a particular credit plan segment on the account, CMS will accept it without a plan number or a store number.

If the transaction is complete and correct and the account has no condition on it to prevent posting, the transaction will post.  When it posts, the transaction leaves the batch.  Transactions that are rejected remain in the batch, which then becomes a reject batch.

Non-Posting

Any batches or transactions that are not posted or warehoused are considered rejected and are placed in the Reject/Reentry file.  CMS provides the Reject/Reentry file to enable you to adjust an entire rejected batch or individual rejected transactions.

CMS will reject an entire batch if:

• The batch is incomplete
• The batch is out of balance.

If a batch was not properly closed at its source, CMS rejects it as incomplete.  The entire batch is placed in the Reject/Reentry file.  The batch will not post until you close it online using the ARMT function.

If a batch’s header and contents do not match, the system rejects the batch as out-of-balance.  The entire batch is placed in the Reject/Reentry file.  The batch will not post until you reopen it using the online Batch Control function (ARBC) and balance it using ARMT.  Balancing is accomplished by modifying the header and/or contents so that they match each other, then closing the batch again.

CMS will reject an individual transaction if:

• The transaction is incomplete (missing information needed for normal posting) or incorrect (contains invalid information)
• A condition on the account prevents normal posting.

 

Example 1:  A sale transaction has no credit plan number on it.  CMS rejects the transaction because it is missing information needed for normal posting.

Example 2:  The account number is not on file.  CMS rejects the transaction because it contains invalid information.

Example 3:  A credit balance refund transaction is in an amount greater than the actual credit balance on the account.  CMS rejects the transaction because of a condition on the account.

Those rejected transactions that contain correctable errors can be modified online using the ARMT function.  Once a rejected transaction has been corrected, CMS will automatically resubmit it for posting.  It is not necessary to manually reenter the transaction.

Those rejected transactions that cannot be corrected can be purged online using transaction codes that evoke special logic modules (Logic Module 88 to purge a non-post debit and Logic Module 89 to purge a non-post credit).

You can use the control record posting parameters covered in this section to force transactions to reject in a variety of circumstances.

Warehousing

Based on control record posting parameters and the current date, CMS may withhold certain transactions from posting until some later date.  Warehousing routinely occurs when an institution uses Active/Inactive Processing or Call Cycle Billing.  Warehoused transactions do not require any online correction.

CMS daily batch and After Hours Processing

CMS Daily Batch

Files from different sub systems (like ITS, ASM etc) are fed to the CMS batch and hence those jobs are executed first and and their ouputs are fed to the CMS batch.

The ITS batch is split up into 2 sub batches as also the CMS batch that is split up into 4 sub batches (CMS1, CMS2, CMS3 and CMS4) depending upon the kind of processing that is done in each batch.

FAS processing takes place along with CMS1 and CMS3 while the ASM (Account Service Management), SSC (Security Sub System), CTA (Collection Tracking and Analysis), CDM (Credit Decision Management), MBS (Merchant Banking Sub System) and LTS (Letter Tracking Sub System) sub-system batches run only once during the nightly batch cycle at specific instances.

The batch cycle can be split up into 4 phases and different sub system jobs run in each phase as detailed below:

Phase 1 : Begin Batch (CMS Onlines are still up and normal day processing still available)

ITS1 à  TRAMS à  ITS2

Phase 2 : After Hours (CMS onlines are brought down, Selective file maintenance available)

ASM and  SSC à  CMS1 (FAS) à CMS2 à CTA, CDM and MBS

Phase 3 : Update  (CMS onlines still down, no processing available)

CMS3 (FAS) and LTS

Phase 4 : Begin Online Day (CMS onlines are brought up again and normal day processing available)

CMS4

The processing done in each sub-system is briefly explained below:

ITS1 – The charge backs and retrieval requests that are entered online in CMS will be extracted and routed to TRAMS.

TRAMS – The input monetary transactions are validated and routed to the various sub-systems here. In addition to this the outgoing requests to various external interfaces like schemes are also handled here.

ITS2 – The incoming retrieval requests and charge backs from other schemes and other sources are routed to the ITS system.

ASM – The batch processing for ASM happens here. External inputs to ASM and the daily house-keeping of ASM records occur here.

CMS1 – Non-monetary and monetary updates happen in this application. In addition to this interface files to external systems like LMS and CTA get generated here.

CMS2 – Processing of Open item billing, update of frequent shopper points, Monetary transaction update, Inactive file processing, Statement file generation, card issue and reject re-entry processing happens here.

CMS3 – All the monetary and non-monetary updates that happened during the after-hours mode will be applied to the main CMS files during this period.

CMS4 – Report and statement generation happens here.

After Hours/ End of Day

During the day, when the onlines are up, all the master files are updated (addition of new accounts, file maintainence etc). In order to trigger the nightly batch cycle AROC transaction needs to be fired.

AROC transaction is the after hours processing screen used to  select a processing mode for CMS master files. Three processing modes are available in this :

1. Normal Processing – All CMS master files are open.

2. After hours processing – All CMS master files are closed and After hours files are opened for Read only. Shadow files are opened for Updations.

3. No processing – All CMS master files are closed to all processing (ARCA mode).

AROC (or ARCH) transaction (Open For After Hours A-H Processing) is fired to close all the CMS files and also open the after hours files. In after hours mode, only certain non-monetary transactions are allowed, monetary transactions are not allowed. AROC internally triggers OFED transaction that sets the End of Day for the FAS sub system (FAS and CMS go hand-in-hand hence at any given point of time, they should be running in the same mode).

Program OFU000 loads control card FWCC into file FTCC. Various FAS programs read the control cards file for execution control.

After the control card load, OFD100 is triggered. It is the first batch program in the FAS end-of-day batch process. This program generates a user input file for the VisionPLUS CMS daily run and generates a backup of the FAS log file (FBLG). This program also produces and passes a report file to OFD110 where all reports are generated. It reads AMCR, FMSC, FMLA, FMLB and FTCC control card file (that was generated by OFU000) and creates the following output files:

FBLG    : Log file (Tape Backup)

ATIA     : CMS authorization transactions to posting

ATUD    : CMS non-monetary transactions

FTRF     : FAS reports file

Some Credit Card Business Jargon

Debit and Credit Transactions:

Any transaction which reduces the amount the card holder can spend is registered as the debit transaction in the account of the card holder. For credit transactions just opposite holds true, i.e. for any transaction which increases the amount the card holder can spend a credit transaction is recorded in the account of the card holder.

Sale (or purchase) and Payment Transactions:

As mentioned above, a sale or purchase transaction is a transaction by which the user makes use of the credit or debit card at any permitted outlet to buy any item or to avail the cash and which in turn reduces the capacity of the card holder to make further purchase transactions.

By any payment transaction, as opposite to the purchase transaction, the card holder pays some amount to the bank which increases the card holder’s capacity to make purchase transactions.

Plan:

A plan is a record to keep details for a particular type of transaction. A plan contains following details for any transaction:

• What interest rate will be applicable for that transaction and from which date it will be applied
• What will be the due date to pay for any transaction
• What other charges will be applicable for that transaction in all the faces like if the user pays in time, if user doesn’t pay in time, if user pays the cheque but it is returned from the bank, and various other such conditions.

Types of plans:

• Cash Plan
• Retail Plan
• Balance Transfers
• Loan Plan

Current Balance:

Current balance is the total amount at any point in time the card holder needs to pay. It is increased with any debit transaction for the account holder (like purchase transaction) and is reduced with the credit transactions made for the account holder (like payment transactions)

Open to Buy:

Open to buy is the amount available for the card holder to spend at any point of time. As opposite to current balance, it is reduced with any debit transaction for the account holder (like purchase transaction) and is increased with the credit transactions made for the account holder (like payment transactions)

Principle Balance:

Principle balance is a component of current balance and it reflects the actual amount the card holder has spent or used whereas, the current balance shows the all the interests and charges levied on to that account in addition to the principle balance.

Credit Limit:

Credit Limit, as the name suggests, is the limit which user can have current balance upto.

Interest Accrual:

When the card holder spends the issuer bank’s money, the bank charges interest on that amount. This interest is accrued until the amount is paid up. There are various methods of accruing interest. They are as follows:

• Daily Accrual
• Monthly Accrual
• Monthly adjusted ending balance

Delinquency:

When the card holder does not pay the amount he is asked to, he becomes delinquent. The more time he takes in paying the more delinquent he becomes. The parameters on which delinquency is measured is as follows:

• Contractual delinquency
• Recency delinquency
• Days delinquency

Billing Cycle:

Billing cycle is the day of the month decided for any account on which all the monthly processing (like interest calculation) required is done.

Cycle to Date:

For any purpose if cycle to date term is used it implies the time from last billing cycle to today’s date (for example cycle to date transactions means the transactions made after last Billing Cycle till today’s date)

Batch:

Term used to describe a group of transactions. A batch of transactions consists of a batch header and the individual transactions. The batch header usually contains the batch number that identifies the batch, the number and amount of debit transactions, and the number and amount of credit transactions.

Batch Processing:

Mode of data processing in which items are accumulated as a group and processed sequentially offline.

Monetary updates:

Any update which affects the currency value of the account (for example any sale transaction posting which will update the monetary status of the account)

Non-monetary updates:

Any update which does not affect the monetary status of the account (like change in address of any account holder)

Demographic Information:

Information regarding the physical location of the cardholder like his country, state, city, zip etc.

Block Codes:

A user-defined code that identifies an account requiring special processing or handling.

Billed-not-paid:

Component on the credit plan segment that increases or decreases when a transaction is posted to an account.

Check Digit:

Digit within an account number that is derived from a computation of a re-determined formula using the other digits of that account number. The check digit is used during the edit process to validate account numbers, customer numbers, card numbers, and store numbers.

Grace Days:

Number of days after a statement is produced during which a finance charge is not assessed if the customer pays the statement balance in full.

Payment Due Date/ Days:

Number of days or a certain date before which if payment is made, no interest or other late charges will be calculated

Statement:

A printed document that furnishes the details of all the
monetary transactions made by the customer in
interregnum between the two billing cycle dates and the
service charges that were incurred by the Customer.

Merchant or Store:

The shops or outlets where the bank or retail card can be used.

 Charge off:

The different stages of an account which does not perform as a normal account.

Stages of charge off

Stage                Account status

None                     0

Potential               1

Pending                2

Auto-initial            5

Manual-initial       6

Final                    9

Collections:

The branch of credit card industry which is responsible for collecting payments from the card holders

Credit Management System (CMS) – Heart of Vision PLUS

A total management system for retail, bankcard, and private label The Credit Management System (CMS) is designed as an on-line parameter-driven, accounts receivable credit management software system.

CMS is the core system of the VisionPLUS family of integrated software products that provide credit processing.

Flexible control of AR processing and tracking

User defined special credit offerings and promotion

Quick and efficient processing and access of AR account information

Management of multiple accounts under one customer

Real-time and batch updates

Comprehensive management reporting

Generation of customized credit letters

Transaction level credit terms

Frequent shopper programs

Variable rates finance charges

Co-branding to enhance partner programs

Insurance product capabilities

Service charges and fees

There are two categories of transactions in CMS: Monetary and Non-Monetary

Monetary transactions affect account balances.

 payments, adjustments, etc.

Non-monetary transactions are those that do not affect account balances.

 maintenance to bill cycles

 customer information changes – name, phone, etc.

Monetary transactions are normally processed in nightly batch processes and are usually received electronically.

Non-Monetary transactions are normally on-line real time transactions. Selected transactions may be entered, but then held until the nightly jobs are run.

General Flow:

On a daily basis (based on parameters set) you may maintain the following items real time:

Account Information

pview and manage customers’ accounts

penter financial adjustments

pchange customer information

Control Processes such as:

pauthorization

pstatement production and reporting

ptransaction posting

On a daily basis (based on parameters set) the following batch jobs may be set to process information.

Monetary Batch Transactions

Frequent Shopper Points of Entry

On a billing cycles basis:

A billing cycle is the interval between days or dates of regularly produced billing statements.

Statements are processed and printed during a billing run.

Multiple billing cycles during a month allow for distribution of work.

The following billing cycle calculations may be performed based on parameters set:

 Calculate payments

 Consolidate payments

 Distribute payments to credit plans

 Apply underpayments and overpayments

 Apply payments to accounts with multiple credit plans

 Handle prepayments and skip payments

 Apply payment reversals.

Setup begins in CMS by establishing the control records.

Each control record handles options and parameters pertinent to specific areas of processing.

The three primary system level control records are:

 System record

 Organization record

 Logo record.

Establishing Control Records:

The are another 21 control records that help control the system. Based on the number of interfaces used, some or all of these will have to be set up.

The remaining control records represent processing levels within one or more of the higher level control records.

What are System Controls?

CMS system control records allow tailoring your processing environment to meet your specific needs.

The system record represents the highest level of controls in CMS.

It enables you to establish the overall processing characteristics for credit processing.

This record also indicates whether CMS interfaces with other systems such as:

 ACS-Adaptive Control System

  ITS-Interchange Transaction System

 LTS-Letter System

What are Organizational Controls?

Within CMS you may set-up multiple organizations.

Organization-level controls define the characteristics and processing parameters for large groups of similar accounts.

By grouping accounts under different organizations, you can divide and control accounts that require different processing parameters.

Things to consider when adding an Organizational control record.

Number of organizations that will be defined.

Processing parameters.

Days of the week on which the organization will process.

Holidays that the organization will observe.

Next billing processing dates

Thing to consider when adding an Organizational control record (continued).

Days of the month billing processing is to take place

General ledger processing

Default general ledger debit and credit account numbers and reporting level for reject reentry

What are Logo Controls?

Logo control records define processing parameters for the various kinds of accounts you process within each organization.

A logo is a logical grouping of accounts categorized by the type of card, processing parameters, and reporting requirements.

Block code in the Logo record is a user-defined code that identifies an account requiring special processing or handling.

Now let us look at Account set up in Vision PLUS,

Each account has at least four records

 Customer Name/Address

 Relationship

 Account Base Segment

 Embosser

After the account has been entered the system generates at least one Plan Segment

Customer Name/Address record contains demographic information on the customer.

Relationship record contains information about associated accounts.

Account Base Segment record contains current and history information and flags that control –

Billing cycle

Processing

Block codes

Card scheme number

Embosser record contains:

Name to be embossed on the plastic card

Type of card requested

Number of cards outstanding

Number of cards returned by the cardholder

Plan Segment records

Are automatically created by the system when monetary activity posts to an account.

Are similar to a “mini-account” within a customer’s account.

to be continued…