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

Vision PLUS Batch Process

In CMS, a Batch process is required to post Monetary transactions (like sale/payment, debit/credit adjustments or refunds etc) as well as Non Monetary transactions (like change of address or telephone number) to the customer’s account, calculate date-driven delinquency, calculate finance charges and late fees, generate statements, and other functions. The batch process is streamlined and capable of processing large account bases within compressed nightly batch windows. During the batch process, all master files are closed to online maintenance so that the batch update can occur. To accommodate certain data  processing requirements, Vision PLUS enables the credit staff to access and/or manipulate cardholder account data after the master files are closed and batch processing begins (in the after hours mode).

The batch processing of accounts can be classified into 2 broad categories as:

1. Non monetary batch flow
2. Monetary batch flow

Non Monetary Batch Flow

At any point of time, if the card holder would like to change his/her details in the master files of the Issuer bank, he/she can call up the Customer Service Centre (also called ASM or Account Service Management) of the Issuer Bank and request for the  required change.

E.g.: Address, Telephone number etc.

These changes are directly updated to the original master files through the online by the customer service representative and a log file (AML1 file that is extracted as ATL1 using the ARD020 program in batch) will be maintained with the before and after value of each of the changed fields. This activity would be performed online for the specific accounts requested for.

On the other hand, if the issuer bank would like to do bulk changes of field values for bunch of accounts, instead of updating through online transactions, they are created through a User input file (ATUD) and then fed into the batch for updating the master files.

E.g.: Postal code of a city changes, Name of a city changes etc.

Here it is important to make sure that the User provided ATUD files are pre-edited before they are fed in the nightly batch to update the master files.

ARU040 (Non Monetary User Input Pre-edit):

ARU040 program will do the pre-edits of all the non-monetary User inputs.\

All the non monetary user inputs are fed into the system through ATUD (Disk)/ ATUT (Tape) files and they are pre-edited by the program ARU040.

Some examples of pre-edits are:

1. If the input record is an “Add New Account” and the account exists on either the AMBS or the AMBI (Inactive Account Base Segment) files, the program rejects the input record.
2. If the input record is a maintenance function to an existing account and if the account is not on the Account Base Segment file or on the inactive file (if the maintenance is base segment maintenance), the program rejects the input record.
3. The input record can also be rejected based on the Field Security Level record for this organization and security user code, or if the data input is not valid for this field.
4. Also, if the value of the field being changed is identical to the value input, the program does not generate a maintenance record.

 

All valid records that have passed the pre-edit are written into the ATUI file and for all the error records a detailed invalid report is generated. The pre-edits are done only for records that belong to AMNA, AMBS, AMED, AMPS, AMPM, AMLS files, and all other file records are bypassed from the pre-edit.

ARU040 is composed of various dynamically called programs. Each of these called programs pre-edit respective files and pass on information to ARU040. These programs are specifically named as ARU040XX, where XX stands for the file name acronym.

E.g.:     ARU040BS:       (Account Base Segment User Non-Monetary Pre-edit) will be called from ARU040                  for AMBS file pre-edit.

ARU040NA:      (Name and Address User Non-Monetary Pre-edit) will be called from ARU040 for                               AMNA file pre-edit.

ARD040 (File Maintenance Journal):

The actual non-monetary maintenance happens in the ARD040 program.

The valid ATUI file from ARU040 is fed as input to ARD040 program, and this program updates the actual master files when it is run in the user-input mode. It also generates the detailed report with before and after values of fields that are updated online, provided it is run in the journal mode (the input file in this mode will be ATL1 which is extracted from AML1 using program ARD020).

ARD040 can be run in three modes – JOURNAL, UPDATE U & UPDATE.

JOURNAL mode – generates report of all non monetary updates that have happened through online. That means all online accepted non monetary transactions in the input ATL1 file, that affects any of the master files will be reported.

UPDATE U mode – Updates the master files using ATUD (Disk File)/ ATUT (Tape File).

In the Update U (also called as user-input mode), the program can do selective updates on CMS master files. In this mode, the program opens only the AMBS, AMEC, AMED, AMNA, AMPM, and AMSC files for direct updates. Corresponding updates are made to AMNK (Name Key File) and AMBX (Customer to Base Segment Cross reference file), if applicable. Also it creates different output files like ATNU (Name Key Update File), ATTS (Promotion Statistics Tag File), ATO1 (CTA Tag Maintenance File), ATNM (Daily Name/Address Maintenance File), ATFR (Fraud Report File) which can be used by other subsystems for different purposes.

UPDATE mode   – Is used for disaster recovery (Reload files from backup – ABTF). The update mode can be used for data recovery operations. In this mode, the valid transactions that are resident on the AML1 file will be applied to the concerned CMS master files during the execution of ARD040.

ARD040 is composed of various dynamically called programs. Each of these called programs processes and passes print file information to ARD040 in both the update and journal modes. These programs are specifically named as ARD040XX, where XX stands for the file name acronym.

E.g.:     ARD040BS:       (Account Base Segment Record Maintenance Journal) will be called from ARD040                              for AMBS file maintenance.

ARD040NA:      (Name and Address File Maintenance Journal) will be called from ARD040 for AMNA file maintenance.

ARU780 (Name Key Update):

The ATNU (Name Key Update File) file created by ARD040 will be fed as input to ARU780 program which handles Alpha search Update. It rebuilds AMNK (Name key file) and AMBX (base customer XREF file) files. AMNK file is used to locate a customer by giving first few alphabets of the name using the online ARNL transaction. Rebuilding of this file is required when there are changes in Name and Address file AMNA.

Monetary batch flow

Monetary transactions are those which affect balances of CMS accounts. Monetary transactions are typically authorized and input by tape or electronic transmission. Other monetary transactions are input using CMS batch transactions (E.g.: Batch of transaction details that the Merchant submits to the bank). These transactions do not affect the balances until a batch processing run is completed. Monetary transactions can be fed to the system mainly through online or through batch.

ARAT/ARAP transaction can be done online which will add a record to the AMT1 file that will be fed to the nightly batch cycle for processing. A few monetary transactions that could be applied through online could be interest adjustment, fee adjustment, re-entering rejected batches, adding payments etc.

On the other hand, the ATTD (Disk)/ATTT (Tape) batch feed will come through TRAMS (Transaction Management System). TRAMS will receive the settlement file from the network that would contain all the monetary transactions that were processed during the day in the network (Master or Visa).

All the monetary transactions are processed in batches and there can be only one batch processed per organization in the batch, hence maximum number of batches would be 99998 in any batch cycle. A batch of transaction consists of a header that contains the batch number, sum totals of all transaction items and debit and credit amounts that are included in the batch, and records of the individual transactions and details. During the daily run, CMS matches the contents of the batch with the batch header. If the batch header does not match with the content, CMS rejects that batch. Either the batch header or the batch will need to be corrected to balance the batch, before CMS will process it.

Monetary transaction flow in CMS is handled by the following programs. The AMT1 file is processed through the following set of programs.

1) ARD020: Online Transaction Extract

2) ARD080: Transaction Edit Merge

3) ARD100: Sort Transactions to Posting

4) ARD140: Posting

5) ARD180: Monetary History Update

6) ARD185: Multiple Reject Processing

7) ARD200: Build Reject Reentry

The ATTD/ATTT file from TRAMS is initially processed through the following set of programs:

• ARD010: TRAMS monetary balancing report
• ARD011: Sort ATTD file for CMS
• ARU080: Monetary user input pre-edit

The output of ARU080, ATTI file is fed to ARD080 along with ATT1 created by ARD020 and the processing continues from ARD080 through ARD200.

ARU020  ( Master file backup/reload):

Program ARU020 is used to take backup or reload all master files. The backup will be taken into tape file ABMF. This is a control card driven program in which we can specify options for backup/reload as well as the file for which we need to perform the operation. If something goes wrong during the batch or for any other reason, if it is required to restore all the master files as is before the batch, ARU020 would be run in the reload mode and using the ABMF as the input file, all the master files would be restored.

ARD020 ( Online Transaction Extract ):

Program ARD020 extracts all online monetary transactions that were fed through ARAT/ARAP screens throughout the day. All these transactions will be added to the AMT1 file. Also we have the rejected monetary transactions form the previous day’s batch in the AMJ1file, the transferred transactions in AMXT file. This program extracts all these files and will create output transactions files   ATT1, ATJ1 and ATXT.

Also this program takes the backup of all the transaction files into tape file ABTF. This tape backup ABTF can be used to reload the transaction files in later stage if required .This Backup and reload process is driven by setting the control card parameters.

ARD060/ARD065 (Date Roll/Date Roll Account):

All the master files in the system have a date and/or timestamp in the header record. In the batch run, all the master files are updated with current system date and time on which the batch is running.

User can make the system bump to any future date by giving a future date in the control card. This would not happen in a normal production environment but would be required in the Test Environment for testing specific functionality (like testing delinquency, calculating future interest etc).

Otherwise the system will increment the date by one from the current date in the AMCR file.

ARD060/ARD065 programs will handle the date roll in CMS. This will update all the files with correct processing date for the system and the organizations. ARD060 does the date and time stamp updates for non segmented master files i.e. the control files. (E.g. AMCR) ARD065 does the date and time stamp updates for all the account based master files. (E.g. AMBS, AMNA etc.,)

ARD011 (Sort monetary file from TRAMS):

Program ARD011 sorts the monetary transaction coming from TRAMS and writes into ATTD file and pass the file to program ARU080. ARD011 sorts the records in the correct sequence i.e. batch headers at the top followed by the transaction records. The monetary data from the ASM system is formatted in ATTD layout and passed into ARU080 program for further processing.

ARU080 (Monetary User Input Pre-edit):

Program ARU080 handles the pre-edit of monetary transactions from the user input files (ATTD, ATTT or both) which are coming from different sources like TRAMS/ ASM, merges the files and writes all valid transactions into ATTI file. It produces a report, listing valid and invalid batches and transactions and corresponding error messages. ATTI file is then passed to program ARD080.

ARD080 (Transaction Edit/Merge)

Program ARD080 merges all monetary transactions and creates the files ATE1 (transactions in error are moved to ATE1), ATNS (all the New Sale transactions are moved to ATNS) and ATVT (all other Various Transactions are moved to ATVT). All balanced batches will be written into ATBB file and imbalance batches into ATIB file.

It merges the following files:

ATT1 (today’s transactions from the online system)

ATJ1 (reject reentry items from the online system)

ATTI (user input)

AMWT (warehoused monetary transactions)

ATXT (today’s transfer transactions)

ARD100 (Sort transactions to posting)

ARD100 sorts & merge all monetary transactions from ATNS & ATVT and creates ATPT (Posted Transactions File) which will be used as input for posting program (ARD140).

ATNS contains all new sales transactions and ATVT contains all the various transactions.

A delete define step runs that will delete and define all the temporary master files.

The intermediate copy step copies the Insurance history master file to the temporary insurance history file.

ARD140 (Posting)

ARD140 is the Posting program with multiple functions.These functions include posting transactions to customer accounts,examining each account for reportable conditions, generating the necessary report tag records, producing statement records , calculating fees assessed by the system , accrues the interest, applies the  payments to the system, sends accounts for collections and  many other tasks.

Program ARD140 does the posting of monetary transactions using ATPT  as input and updates the master files.Also ARD140 generates several transactions for assessing fees, billing interest, interest adjustments etc and post to the customer accounts.These generated transacations will be available in the ATGT file created by ARD140.It updates the posting flag in ATPT and ATGTfiles with any value ranging from 00 to 99. If the posting flag is other than zero, then it signifies that the transaction hasn’t been posted to the system.  A transaction can be rejected (for many reasons) or warehoused.. These transactions

ARD140 is a driver program which calls many sub modules like D140ATPT,D140DELQ, D140INT, D140LM30 etc to handle different types of tasks in posting. Each copybook has a prefix of D140 and a 3 or 4 character file name (such as AMBI) or function name (such as INS). For example D140AMBI is the inactive account processing copybook and D140INS is the Insurance processing copybook. ARD140 is the top level routine and controls the overall processing flow, performing the various functions as necessary.

ARD170 (Shopper Program Control Records Update)

ARD170 updates the Frequent Shopper statistics that are accumulated as part of the program after multiple postings are run. ARD170 updates the Frequent Shopper Program (AMSP) control file using records in the Shopper Profile Update (ATSP) file.

ARD175 (Sort ATGT and create ABGT Backup)

ARD175 sorts and backs up the generated transactions which are created by posting in the generated transaction ATGT file.

ARD180 (Monetary History Update)

ARD180 processes the various monetary transaction files after they have been processed by the posting program ARD140. It distributes these items to various output files depending on whether the:

• Transaction was posted or non-posted.
• Transactions are to be printed in a statement run today.

The program reads  each of the four input files  – ATGT, ATPT, ABAI and AMDI.

Depending on the posting status and the statement status, the transaction will be routed to either of the five output files:

1. a) Unapplied or nonposted transactions from the ATPT file are routed to the ATTA file.
2. b) Monetary transactions from both ATPT and ATGT files to be warehoused are routed to the AMWT file.
3. c) Accumulated history back up transactions are routed to the ABAO file. This file contains all posted transactions from the ATPT file, the ATGT file, and the ABAI file for those accounts not printing on statements today
4. d) Statement monetary transactions are routed to the ATST file. This file contains the same transactions as the ABAO file described above for those accounts printing on statements today. It also contains any disputed items from the AMDI file for the indicated accounts.
5. e) Unstatemented posted monetary transactions are routed to the AMOS file.

ARU060 (Initialize Transaction Files)

ARU060 program initializes the transaction files of the system. It initializes the files like AMJ1, AML1-4, AMM1, AMT1, AMXT, AMOM, AMBM, AMOM, AMBM, AMOM, ATTD, ATTT, ATUD and ATUT to make them ready for the next day update/processing.

ARD185 (Multiple Reject Processing)

ARD185 takes  all those  transactions,  that are rejected by posting for multiple reasons  and generates Multiple reject records in the ATM1 file. (one record each for each  reject reason). This will list the multiple reasons because of  which an account got rejected in posting. This will be useful when we correct the rejected transactions thru online  for Reject re-entry.

It uses various input files (AMHB / AMMC/ AMBI/ AMBS/  AMCR/ AMDI/ AMOA/ AMPS/ AMRT) to create ATM1 and the program  also updates the ATTA file.

ARD190 (Build Multiple Reject AMM1 File)

ARD190 creates the Multiple Reject AMM1 file with one record each for every reject reason using ATM1(temporary multiple reject reasons) file as input. It also generates the Multiple Reject Report.

ARD200 (Build Reject Reentry)

ARD200 loads the rejected transactions from the day’s batch run to the Reject Master (AMJ1) file. It also generates the Reject Reentry Batches Report. It uses AMCR, ATTA and ATE1 as input and generates AMJ1 and takes the tape backup in the Rejected Transactions Backup file ABJ1. These rejected transactions can be corrected thru online  ( ARMT) baed on the reject reasons  so that they can come into the system in the next days batch processing.

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…

 

Introduction to Vision PLUS

Vision PLUS is a financial software application from First Data Corporation. Originally developed by the Paysys Research and Development Group, this application is mainly used for credit card transaction processing by multinational banks and transaction processing companies. Various banks and financial institutions use this software application to store and process credit card, debit card, prepaid, closed end loan accounts and process financial transactions (Visa, Mastercard, American Express, Europay, private label transactions) against those accounts. The rough estimate of number of cards processed on different versions of this application software around the world is 360 million.

VisionPLUS offers financial institutions the flexibility to configure their own product features and functionality. It is a family of totally integrated software products. VisionPLUS consists of modules that work together to fully manage your company’s credit environment. As stand-alone applications, they are very impressive, as a totally integrated and interactive unit, VisionPLUS is extremely powerful.  CMS is the core module and plays an important part, as all account related activities are posted in the CMS module.

VisionPLUS has outstanding batch processing capability that increases speed and efficiency. Its single-pass master file system assures timely processing windows while updating every account each night. This means dramatically increased productivity for personnel in credit operations and data processing. With VisionPLUS, everyone in the information “loop” has access to data on a real-time basis. Credit operations personnel will be aware of any change in account status as soon as it happens regardless of whether the change is made through customer service, collections, or authorizations. Online, real-time information such as customer history, purchase patterns, and a wide range of demographic and behavioral data means you can respond proactively to your marketplace and gain the critical edge on your competition.
Because VisionPLUS shares information among all applications, credit management personnel get the “big picture” rather than isolated bits and pieces of data. You can analyze customer buying trends, respond quickly to the merchandising group’s efforts to drive up sales, and turn your credit management operation into a highly profitable merchandising tool. VisionPLUS provides the necessary information tools to increase customer satisfaction and facilitate repeat sales. Customer service is paramount in creating customer loyalty and enhancing your company’s image after the sale. With access to real-time cardholder information in a paperless environment, representatives can deliver the quality service your customers expect and deserve.
All facets of your credit organization, from new accounts to customer billing, from authorizations to collections, from management to customer service, need information that is reliable, accessible, up-to-date, and centralized – information available through VisionPLUS applications.

Taking a Closer Look at the VisionPLUS Modules, the purpose of each of the VisionPLUS modules is described in the following subsections.
CDM
The Credit Decision Management system (CDM) is the new accounts module. This online system is designed to handle the credit approval process from the point of application to the point of approval or decline. Applications are taken through processing steps that mirror the underwriting process and can be categorized and treated according to the parameters set by your company. While the entire process can be automated, human intervention can occur at any point within the process, the choice is yours.
CMS
The Credit Management System (CMS) is the accounts receivable system that functions as the heart of VisionPLUS. CMS holds the demographic, financial, and historical information for each account. Other VisionPLUS modules needing that information obtain it from CMS, eliminating record duplication. CMS also contains user-defined parameters for interest, billing, insurance, payment, and account processing.
ASM
The Account Services Management system (ASM) is the online, real-time customer service module. ASM enhances your ability to provide superior customer service by utilizing user-defined action codes to perform customer-generated requests such as interest adjustments, address changes, and disputes.
FAS
The Financial Authorization System (FAS) is the 24-hour-a-day, 7-day-a-week authorization module. FAS processes retail, Visa, MasterCard, and Europay authorizations based upon user defined processing parameters. Authorizations can be approved, declined, or referred. FAS also provides authorization reversals, card recovery listing and updates, and event/delayed advice retrievals.
TRAMS
The Transaction Management System (TRAMS) is the VisionPLUS front-end processor. TRAMS accepts multiple transaction types and prepares them for any destination, consolidating numerous application front-ends into a single input system. TRAMS also provides extensive job tracking, settlement, warehousing, reporting, reject, and online reject and suspense handling capabilities.
MBS
The Merchant Bankcard System (MBS) is the merchant acquiring system. MBS supports both bankcard and retail merchant processing providing an efficient way to settle funds and charge the merchant fees for services rendered. MBS offers discount, participation, reserve funding, and volume bonus processing along with comprehensive activity reporting.
LTS
The Letter System (LTS) is the module that can be used to create and issue letters for up to five different PaySys products. Letter variables from these different modules can be embedded within generic letters to produce letters tailored to individual customers. Letters can be printed real-time or in batch processing.
ITS
The Interchange Tracking System (ITS) is the dispute tracking and processing module. ITS is designed to process incoming and outgoing chargeback transactions for both Visa, MasterCard, as well as some regional associations such as Europay (for Eurocard-MasterCard only) and Australian Bankcard. ITS keeps track of many user-defined parameters, such as time limits to keep your business compliant with the different associations. Chargebacks are “worked” through queues based on criteria that you define creating a customized, organized workflow.
CTA
The Collections, Tracking, and Analysis module (CTA) is designed to categorize and treat accounts that need special handling. While the system was designed primarily to handle past-due accounts, it can be used to track and analyze other groups of accounts that may or may not need actual treatment. These groups may include VIPs, lost or stolen cards, overlimit accounts, and bankruptcy cases. CTA offers flexible collection strategies based on how your company sets the control record parameters.

Each of the VisionPLUS modules is a powerful, valuable credit-processing tool. As an integrated system, VisionPLUS creates a comprehensive credit processing environment, providing your business with the flexibility, and reliability needed to succeed.