Merchant Banking System (MBS) Overview

Primary Control Record

Secondary Control Records

Preamble for further screens:

At Org level 5 stmt messages can be defined. On Merchant level any one or more of these can be selected to be populated on the merchant statements.
MBS allows nearly 46 system fees and 10 user fees. For user fees the title can be defined at org level. This titles are displayed in the merchant statements.
At the merchant level 8 user dates, 8 user amounts and 8 user data are allowed. The title of all this fields ( to be shown on corresponding screen ) can be assigned at the org level.
On the MBMO12 screen, 99 valid products with their status at the org level can be defined. Any merchant within this org can use only the active products within this org.

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.

Interchange tracking system (ITS)

ITS is used to track Incoming & Outgoing Visa & MasterCard Interchange items.

Role of ITS:

Outgoing Activities for Issuer

» Copy Request

» Chargeback

» Misc Fee Claim (Funds Disbursement/Fee Claim)

Commercial card processing

CMS and HCS work together to provide commercial card processing and reporting.  HCS provides management of the company structure and account creation as well as reporting in the form of organization level reports and interfaces to Master card Smart Data and VISA INFOSPAN.

The structure of HCS depends on a business’s organizational chart.  Each entity in HCS is considered a “node”.  A node could be a company, a cost center, or an individual account.  A company can have up to 99 levels and up to 999,999,999 reporting units which could be representative of a division, department, cost center etc.  HCS can also support up to 999 products (CMS Logo).

• Company Node – Highest level in the HCS hierarchy. The company node contains node information that defaults from the Company Master record.
• Reporting Node – Node or “entity” representing an intermediate level in the company hierarchy, such as a specific division or cost center. This type of node contains name and address information to identify the business unit that is represented. These nodes serve as reporting unites and track summary account information

Account Node – Represent individual accounts and are attached to reporting nodes.  This node is always the lowest level of the hierarchical structure, but can be attached to any reporting node, regardless of level.  An account node can represent an actual cardholder, or it can represent a billing account used by CMS sweep processing provides the account processing and passes transaction and account information to HCS.

The Hierarchy Company System (HCS) is an application that provides a company hierarchy structure for processing commercial cars and managing the relationship between the company, the sublevel reporting within the company, and the individual commercial card accounts.

HCS supports multiple hierarchical levels, multiple card products, statement processing, reporting, letters, and transfers for each company.

HCS interfaces to the Credit Management System (CMS) to obtain transaction activity and provide accounts-receivable information.

 

Take a look at Vision PLUS Messaging framework

VMx as they say in short is available for purchase to licensed clients. It provided distributed access to Vision plus modules,

What is the need of VMx?

Complex enterprise environments

–Emphasis on CRM(Customer Relationship Management)

–Many interactive systems

–Mainframe vs. IVR / VRU, online banking, call center, etc.

–Need real-time access to card system data / functions

VisionPLUS <8.17 = legacy architecture

–File & screen model (human<->system paradigm)

–Functions & data tied directly to presentation

–Suitable for 3270 (green-screen) model

–Difficult to interact with system other than online

–Requires invasive interface code

–Interface code requires regular updates / retrofits

So it gave rise to birth of new definitions:

SBA = Service Based Architecture:

Foundation technology for future VisionPLUS enhancements (8.17 and beyond)

SDM = Service Delivery Manager (part of SBA):

Broker for message routing between service consumers and providers

VMx = VisionPLUS messaging framework:

Expands services concept for full systems integration

SBA changes the real-time model

–Separates data / function from presentation (online)

–Defines business ‘services’ to get data or perform functions

–Isolates applications & data from external invasion

–Enables re-use of services

–By humans (online)

–By other host-based systems (CRM, loans, deposits, etc.)

èVMx goes beyond mainframe

–Communicates with other platforms

–Uses services defined under SBA

SBA is a concept, implemented in VisionPLUS as

SDM / “Service Delivery Manager”

SDM developed in 2004

–Part of VisionPLUS 8.17 release

–Added to common modules in SSC

–Includes

–Service Delivery Manager (SDM)

–Services repository (SMSD)

 

SBA converts systems into service providers

e.g., VisionPLUS applications

SDM directs service messages

–Consumers request services

–Providers “own” services and respond to requests

SDM works within host environment

–Among VisionPLUS modules

–Between VisionPLUS and other mainframe applications

VMx routes messages among environments

–Works through SDM for VisionPLUS services

So we reach below shown architecture of VMx:

VMX

Supports multiple protocols

Promotes platform independence

Makes integration truly seamless

Interprets messages between systems

Accesses any VisionPLUS data*

Builds its own metadata

Encapsulates VisionPLUS modules

to be continued…

General Ledger Record

For each monetary transaction code you define, you must establish corresponding debit
and credit general ledger account numbers. You can define a General Ledger record for
each organization you process. If you prefer, you can establish the General Ledger record
at the logo, store, or credit plan master level within an organization. This level must
correspond to the general ledger reporting level you defined on the Organization record
(GENERAL LEDGER REPORTING LEVEL fields on ARMO03). For example, if you select the
option to report your general ledger at the store level within an organization, you must
enter the valid organization and store numbers on the General Ledger record.
For each organization established in CMS, you must define a set of general ledger account
numbers for the reporting level defined on the organization. You can also assign a unique
reporting description to each monetary transaction using the General Ledger record.
During batch processing, CMS verifies that the required general ledger entries have been
completed before balancing the daily job stream.

 

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.

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.