News

First Data enhances VisionPLUS payment

solution to V+ FLEX
First Data Corporation, a global provider of electronic commerce and payment processing services, has enhanced its
VisionPLUS payment solution with the complementary functionalities of VisionPLUS Flex, a software solution available for
delivery to financial institutions as a server-based appliance.

In a single platform, the VisionPLUS Flex solution supports issuing and acquiring of credit, debit, prepaid, consumer and
commercial cards for private label, American Express, JCB, MasterCard and Visa, as well as consumer loans. It also
delivers an extensive range of payment services and value-added options such as multi-currency and multi-language
capabilities, and allows financial institutions to configure the settings and options they desire within the product.

CMS 8.39 User Operations and Concepts Guide

System Record Controls - Controls that you establish in the System record define the overall
characteristics and data processing requirements for CMS. You do not add a System record using an
online function because this record is normally added during CMS installation. You can use the System
Record screens to modify (ARMS) and view (ARQS) the System record

You can use the System Record screens to modify (ARMS) and view (ARQS) the System record

The System record enables you to: ‰ Specify the days of the week your center is open for
processing. ‰

Specify the holidays or days your center is closed. ‰

Indicate the title of your processing cente to reflect in reports.

Indicate whether the debug tracking feature is active in the Posting program (ARD140).

‰ Indicate whether ACH participation and prenoting is active for the system.

‰ Define the days of the month on which CMS performs cycle processing for accounts.

These cycle processing days are referred to as cycles codes. You must establish valid cycle codes
on the System record before you can assign cycles to your accounts

Code that identifies the country for which CMS is processing

‰ Default currency code that CMS should use when an organization currency code is not
available

‰ Flag that indicates whether the dual currency feature is active

‰ Flag that indicates whether smart card processing is allowed

‰ Flag that indicates whether the prepaid card functionality is active.

 USER GUIDE

CHAPTER 45

Open Item Billing

---------------------------------------------------------------------------------------------------------------------

Prepare ARMH/ARAH/ARQH Frequent Shopper Points Entry

POSTING Routines D140---- payment,delq,int

---------------------------------------------------------------------------------------------------------------------

-AVAILABLCMS 8.0 Screens Guide.pdf

Appendix A Appendix A Monetary Transactions/ Logic Modules

READ FIRST:
https://learnpaymentcard.wordpress.com/2016/02/01/batch-process/

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

 Non monetary batch flow

 Monetary batch flow

Non Monetary Batch Flow

ARD020
AML1 file that is extracted as ATL1 using the ARD020 program in batch.

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

ARU040 (Non Monetary User Input Pre-edit):

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

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.
ARU780 (Name Key Update)
when there are changes in Name and Address file AMNA.

Monetary batch flow

[[[[[[[[[[[[[[[[[[[[[[[

Daily Processing

ARD020 Backup Transaction Files

ARD060 Date Roll – Date/Time Stamp Check Control File

ARU080 User Input Monetary Pre-edit and Merge

ARD100 Sort Transactions to Posting

ARD140 Monetary Posting

ARD200 Reject Reentry Processing

Monetary Flow::

Screens::

• ARAT/ARMT/ARQT :: Monetary Batch

Transactions (Add,MOD,QUERY)

Can be used for any type of monetary transaction.

Consists of a Batch Header record with control figures for the

number of items and total debits and credits in the batch, followed
by an entry page.

ARMT can be used to modify the transaction details of already

entered batches.

ARQT can be used to browse the transaction details.

 ARMT/ARQT functions can also be used for AMJ1 (Reject
Reentry) and AMM1 (Multiple Rejects) files.

• ARAP/ARMP/ARQP

Function used to enter monetary batches for Payment

transactions online in CMS.

Can be used for payment transactions.

Consists of a Batch Header record with control figures for the

number of items and total debits and credits in the batch, followed
by an entry page.

ARMP can be used to modify the transaction details of already

entered batches.

ARQP can be used to browse the transaction details.

ARMP/ARQP functions can also be used for AMJ1 (Reject

Reentry) and AMM1 (Multiple Rejects) files.

• ARDH

• Function used to display Header information

of the monetary batches online in CMS

• Depending upon the option selected the

Header information will be displayed for all Completed/
Deleted/ Incomplete batches

• The function can be used for AMJ1 (Reject

Reentry) and AMM1 (Multiple Rejects) files.

• ARBC

Function used to update the Batch status of the monetary

batches online in CMS.
 Following options are available:

R – Reactivate the Batch; Changes the Completed Batch Status ‘C’ to

Incomplete Status ‘I’

D – Delete the Batch; The batch is flagged for deletion

U – Unlock the Batch; The Batch is unlocked to be edited through

ARMT/ARMP screens.

The function can be used for AMJ1 (Reject Reentry) and AMM1 (Multiple
Rejects) files.

Batch Flow of Monetary Transactions::

Trams input

ARD010- generates the TRAMS Monetary Balancing Report (R50), which shows the
transaction totals fed from TRAMS to CMS

ARD011- Creates BATCH HEADER for the file generated in ARD010

:

ARU080 - ARU080 edits the User Input (ATTT, ATTD, or both) files, merges the files, and
writes the complete batches to ATTI. It produces a report, listing valid and invalid batches and
transactions and corresponding error messages

Monetary extract Flow

ARD020 - Online Transaction Extract.(ARAT/ARAP – ATT1) . A backup function loads the

transactions to a tape file and a reload function generates the sequential

Note: ARD020-ONLINE FILES(ATT1),ARU080- TRAMS FILES(o/p ATTI)

Final merge of all monetary tnxs ARD080 – Merges ‰ ATJ1 (Sequential

Rejected Transactions) ‰ ATT1 (Sequential Monetary Transactions) ‰ ATTI (Merged User Monetary)
‰ ATXT (Temporary Transferred Transactions) ‰ AMWT (Warehoused Monetary Transactions

I/P FILES: ATT1,ATJ1,AMXT,ATTI

O/P FILES: ATE1, ATBB, ATIB,ATNS,ATVT

ARD100 – Reads ATNS-New sale transaction file and ATVT-Various

transaction file and sort and writes to ATPT and ATUC

ARD140 – Posting flag. D140DELQ. D140DELQ performs the following functions:

Section A⎯Computes delinquent days for an account Section B⎯Updates the account’s 24-month status
and payment history Section C⎯Adjusts payment due fields and payment history records to reflect a
recently requested payment Section D⎯Applies a credit to the total amount due and payment accumulators
Section E⎯For payment reversals, this routine adjusts the payment accumulators to reflect conditions prior
to payment Section F⎯Insures that the account base segment and credit plan segments are equal Section
G⎯Modifies an account’s delinquency status due to an improved payment profile. Section H⎯Computes
the reage times for an account. Section I—Processes batch reaging for an account

D140INT Interest Processing

D140PMTC Payment Calculations D140PMTC is a copybook in ARD140 that performs payment

calculations. Program flow This program consolidates payment plans that meet criteria for calculating a
payment. After a payment is calculated, the amount is distributed back to the combined plans by either the
pro rata method or the LIFO (last in, first out)/FIFO (first in, first out) method. The LIFO/FIFO method
distributes the calculated payment to plans containing a billednot-paid (BNP) amount first. Then it
distributes any remaining amount to the plans in a LIFO or FIFO method depending on the logo opti

ARD180

ARD185

ARD200 – reject re-entry

Non-Monetary Flow::

Non Monetary updates can be done through the BATCH and through the
ONLINE region.

The log file for BATCH updates is ATUD and for ONLINE updates is AML1.

Both ATUD and AML1 have the same record layout.

• ARU040 – Non-Monetary Pre-Edit

 • Batch Pre-Edits; Similar to Online Validations

• Different Input Files for Pre-Edit; AMBS,

AMNA, AMED, AMPS, AMRM, AMSC

• Reports Printed for Pre-Edit (T040)

• ARD040

• Different Input Files; which are updated

AMBS, AMNA, AMED, AMRT, AMPS, AMRM, AMSC

• Various Reports Generated

• Three modes of ARD040; Journal, User Input,

Recovery

• Significance of all these modes

• Every field that can be updated online/batch is associated

with a field security.

• The field security details are stored in the AMFS file and
can be seen on the ARFS screen.

Delinquency Overview

Delinquency is defined as the failure to make a payment on an obligation

when due. In CMS, an account’s level of delinquency is expressed in three
ways:

• Cycle due (contractual delinquency)

• Recency (recent)delinquency

• Days delinquent.

CMS automatically ages every cardholder account in these three ways

according to guidelines that you establish on the Logo record. Also at the
logo level are parameters for automatically reaging accounts when
delinquency is to be forgiven.

Cycle Due

Cycle due (contractual delinquency) is defined as the number of cycles that

an account is past due.Cycle due is the traditional method of aging
accounts for delinquency (30 days, 60 days, and so on). Cycle due codes
range from 0 (the account has a zero balance and nothing due) to 9 (the
account has an amount that is 210+ days past due).

Cycle due aging is based on a payment variance that you establish on the
Logo record. If the payment received is less than the payment requested
but within the variance, CMS will not increase the account’s cycle due.

Recency Delinquency

Recency delinquency is defined as the number of cycles since the last

qualifying payment on the account. Recency aging is less strict than cycle
due aging because it acknowledges when the cardholder is making small
payments in an effort to reduce the delinquency on the account. Recency
codes also range from 0 (the account has a zero balance and nothing due)
to 9 (the account has not had a qualifying payment in the past 9 cycles).

Recency aging is based on how you define qualifying payment parameters

on the Logo record. According to these parameters, CMS will either not
increase an account’s recency delinquency or reset the account’s recency
delinquency to zero.

Days Delinquent

Days delinquent are defined as the account’s cycle due (30 days, 60 days,
and so on) plus the number of days that have elapsed since the account’s
last payment due date or statement date.

Both cycle due and days delinquent are affected by how you control when
delinquency aging occurs.
Controlling When Delinquency Aging Occurs

ARML PAGE 13

ARML ( ) **** USER DEFINED TITLE ****** PAGE 13

01/05/2001

LOGO RECORD
09:16:01

ORGANIZATION 100 LOGO 112

PROCESSING CONTROL OPTIONS PERM ISS ID ( )

ISS ID ( FL )

DELQ AGING ( S ) NEW CARDS ( Y ) PLAN

STRUCTURE ( P )

1ST USAGE FLAG ( Y ) P/D DAYS 1 ( N ) ( 99 ) P/D DAYS 2

( 99 )

1ST USAGE LETTER ( 001 ) P/D LETTER 1 ( ) P/D LETTER

2 ( )

ADDRESS CHG EFFECT ( F ) AUTH DURATION ( N ) # ISSUE

ATTEMPTS ( 006 )

FIRST CARD DAY ( 99 ) MAXIMUM CREDIT LIMIT

( 00100000000000000 )

OVERLIMIT RPT % ( 110 ) OVERLIMIT LTR % ( 000 ) OVERLIMIT

AUTH % ( 110 )

OVERLIMIT LETTER ( ) ITS ORG ( 001 ) CREDIT

BUREAU MTHS ( 00 )

ALL STMTS - FLAG ( N ) FLAG EXPIRE ( ) DISPUTE

LETTER ( )

CLLTRL RET MONTHS ( 06 ) BATCH STTLMT QUOTE ( 0 ) CARD TERM

MONTHS ( 024 )

AUTO CLOSE MONTHS ( 06 ) AUTO PURGE MONTHS ( 06 ) AUTO CHGOFF

MONTHS ( 06 )
 LETTER ORG ( 100 ) INACTIVE MONTHS ( 06 ) PLAN PURGE
DAYS ( 090 )

DD CHG LETTER CD ( ) INSTALLMNT ACTIVE ( 0 ) STMT FREQ

( 01 )

LOAN FORCE CYCLE ( 0 )

LOAN PL PRG
DAYS ( 090 )

PSEUDO LETTER: NC PMT ( ) CASH PMT ( )

ASSOC TYPE MAIL CONTROL 1 2 3 4 5 6 7

8 9

STMT CD ( 0 ) ( 0 ) ( 0 ) ( 0 ) ( 0 ) ( 0 ) ( 0
) ( 0 ) ( 0 )

LTR CD ( 0 ) ( 0 ) ( 0 ) ( 0 ) ( 0 ) ( 0 ) ( 0
) ( 0 ) ( 0 )

CURRENCY 840 NOD 2 PER ITEM NOD 2

PERCENTAGE NOD 7

PF1=ARMU PF2=ARMS PF3=ARMO PF4=ARMG PF5=ARMC

PF6=INQUIRY

Related Fields

DELQ AGING

Code that specifies whether delinquency aging occurs on the payment due
date or the statement date. The values are:

D = Age delinquency on payment due date (Default)

S = Age delinquency on cycle date.

The following examples show the results of payment due date and cycle
date aging on both cycle due and days delinquent.

Assume that the account’s cycle date was August 1, that its payment due
date is August 24, and that its next statement date is September 1.

Example 1:

If delinquency aging occurs on the…

The account is considered…

Payment date (August 24)

A cycle due 2 (1-29 days past due) on August 24 and 1 day delinquent on
August 25.

Example 2:

If delinquency aging occurs on the…

The account is considered…

Cycle date (September 1)

A cycle due 2 (1-29 days past due) on September 1 and 1 day delinquent
on September 2.

Cycle Due Delinquency

An account’s payment history is tracked by billing cycle. The cycle due
value assigned to an account indicates its level of contractual delinquency.
You can also think of the cycle due as the number of cycles that an account
is past due.

CMS assigns cycle due values to accounts as follows:

This cycle due code…

Means the account has…

A zero balance, nothing due

Only the current amount due, nothing past due

An amount past due 1-29 days (x days)

An amount past due 30 days

An amount past due 60 days

An amount past due 90 days

An amount past due 120 days

An amount past due 150 days

An amount past due 180 days

An amount past due 210+ days

Payment Variance

You can control whether an account is technically delinquent when the

payment amount received is less than the payment amount requested.
Using the PAYMENT VARIANCE field on ARML14, you can specify a
maximum amount or percentage that a payment can be short and still be
considered a full payment for the purpose of aging an account
contractually.

• When you receive an underpayment within the variance,

CMS will reage the account. Any outstanding billed amount
remaining from the underpayment is not waived but is rolled up into
the previous delinquency bucket.

• If the underpayment is not within the variance, however,

the account becomes delinquent.

Payoff Variance

The PAYOFF VARIANCE, which is also on ARML14, is a two-part field

similar to the PAYMENT VARIANCE. It indicates the maximum amount or
percentage that a payment may be short and still qualify as a full payment
for the purpose of waiving interest due to grace days.
ARML PAGE 14

ARML ( ) ** USER DEFINED TITLE ** PAGE 14

11/13/2001

LOGO RECORD
13:30:20

ORGANIZATION 100 LOGO 101

PROCESSING CONTROL OPTIONS (CONT.) BILL THRESH

( 000001000 )

MIN REAGE MONTHS ( 12 ) REAGE PERIOD ( 036 ) REAGE PERIOD

LIMIT ( 2 )

PROC CONTROL LEVEL ( O ) PRE-PAY ALLOWED ( 2 ) PRE-PAY

MONTHS ( 03 )

BILL EVEN AMOUNTS ( Y ) BILL OVER

LIMIT ( N )

SKIP ALLOWED ( Y ) SKIP SELECTED ( N ) SKIP EXPIRES

( )

REAGED AT ( C ) ( 030 ) REAGE FREQ ( 24 ) REAGE CD LVL

( 4 )

FLEX BILL MONTHS ( 00 ) PREPAY ZERO ( 1 ) PLAN PAYMENT

( F )

PAYMENT VARIANCE ( A ) ( 000000500 ) DELINQUENCY INTEREST

LEVEL ( 4 )

PAYOFF VARIANCE A ( 000001000 ) P ( 0000000 ) MAX

( 000000000 )

QUAL PMT A ( 000002000 ) P ( 9000000 ) NOM BILL OVERLIMIT

( 1 )

QUAL PAYMENT RESET % ( 090 ) C/O CREDIT APPLICATION

F/L/B ( F )

PAYMENT APPLICATION LVL ( P ) MIN DELQ AMT

( 00000000000005000 )
 UNDER PAYMENT 1-4 F/L OVER PAYMENT 1-4
F/L

REVOLVING ( 1 ) ( F ) REVOLVING ( 1 )
( F )

DEFERRED INT-F/C ( 1 ) ( F ) DEFERRED INT-F/C ( 1 )

( F )

DEFERRED PAYMENT ( 1 ) ( F ) DEFERRED PAYMENT ( 1 )

( F )

DEFERRED BILLING ( 1 ) ( F ) DEFERRED BILLING ( 1 )

( F )

OTB: CR BAL ( 0 ) DISP ( 0 ) LOAN AMT ( 1 )

AUTH DAYS - APP ( 10 ) AUTH DAYS - DECL ( 15 ) AUTH VARIANCE

( 1500000 )

CURRENCY 840 NOD 2 PER ITEM NOD 2

PERCENTAGE NOD 7

PF1=ARMU PF2=ARMS PF3=ARMO PF4=ARMG PF5=ARMC

PF6=INQUIRY

Related Fields

BILL THRESH

Amount that determines whether CMS generates a no activity statement for

accounts processed by the logo. If the account balance is less than this
amount, a statement is not sent.
The payment variance amount can be equal to or greater than, but should
never be less than, the bill threshold amount.

Payment Variance

Two-part field that indicates the maximum amount a payment can be short
and still considered full payment for delinquency aging purposes.

The first part indicates whether the shortage amount is a fixed amount or a
percentage of the payment. The values are:

A = Amount (Default)

P = Percentage of the payment.

The second part is the actual amount or percentage.

Examples: If working with U.S. dollars, enter the amount $5.00 as

0000500. Or, for Percentage NOD 7, enter the percentage 10% as
1000000.

PAYOFF VARIANCE /
a/p / max

Three-part field that indicates the maximum amount a payment can be

short and still qualify to waive interest for full payment within grace days.
The first part of this field (A) is the amount a payment can be short in
monetary units and subunits. The second part of this field (P) is the
percentage a payment can be short.

The third part of this field (max) is the maximum amount, in monetary units
and subunits, a payment can be short when calculated by the percentage.
If the amount calculated with the percentage is greater than the max
amount, the max amount is the maximum amount a payment can be short.
If you enter both an amount (A) and a percentage (P), a payment must
meet both conditions to qualify to waive interest.

Examples: If working with U.S. dollars, enter the amount $5.00 as

0000500. For Percentage NOD 7, enter the percentage 10% as 1000000.

Delinquency Interest Level

In some environments, it is necessary to track interest on delinquent

accounts separately from interest on accounts that are current. In CMS,
this is accomplished by defining a unique transaction code for BILLED
DELINQUENCY FIN CHGS on the first page of the Monetary Transaction
Control (ARMX01).

Using the DELINQUENCY INTEREST LEVEL field on ARML14, you can

specify the cycle due level at which CMS will begin recognising and
reporting interest on delinquent accounts.

Statement and Letter Generation Based on Cycle Due

Using the STMT CD and LTR CD fields on ARML13, you can specify the
cycle due levels at which statements and letters will be sent to the
associated party on an account.

Other Logo Parameters Based on Cycle Due

Elsewhere on the Logo record, there are other controls that can affect an
account’s processing based on cycle due.

• Using the BLOCK CODE MATRIX on ARML07 and 08,

you can direct the system to place a block code on an account
automatically, based on the account’s cycle due.

• Fields under the heading DELINQUENCY POINT

CONTROL on ARML11 allow you to affect an account’s
participation in Frequent Shoppers Programs based on its cycle
due.

• The DD ACH CYCLE DUE and DC ACH CYCLE DUE

fields on ARML12 allow you to cancel an account’s direct debit
and credit participation based on its cycle due.

• The CYCLE field on ARML24 allows you to specify the

cycle due level at which automatic charge-off processing will
commence.

Recency Delinquency

Recency delinquency is defined as the number of billing cycles since the

last qualifying payment on the account. The qualifying payment is a similar
concept to the payment variance associated with contractual delinquency.
It enables you to specify an underpayment amount or percentage that
represents a full payment for the purpose of aging an account by recency.

Qualifying Payment
Using the QUAL PMT fields on ARML14, you can specify the amount (A)
and percentage (P) that together define the qualifying payment.

If…

Then…

The payment last requested is equal to or less than A

The entire payment must be made in order to qualify.

The payment last requested is greater than A

Payment made must be P of the requested payment or A, whichever is

greater.

Qualifying Payment Reset Percentage

The QUAL PMT fields prevent recency from advancing. A related field on
ARML14, the QUAL PAYMENT RESET %, will reset the recency of an
account to zero if cycle-to-date payments equal the percentage specified
there.

Other Logo Parameters Based on Recency

Elsewhere on the Logo record, there are other controls that can affect an
account’s processing based on recency.
 • Using the BLOCK CODE MATRIX on ARML07 and 08,
you can direct the system to place a block code on an account
automatically, based on the account’s recency.

• The RECENCY field on ARML24 allows you to specify the

cycle due level at which automatic charge-off processing will
commence.

Days Delinquent

If the DELQ AGING field on ARML13 is set to D (payment due date), then
days delinquent are defined as the account’s cycle due days plus the days
that have elapsed since the last payment due date.

If the DELQ AGING field on ARML13 is set to S (statement date), then

days delinquent are defined as the account’s cycle due days plus the days
that have elapsed since the last statement date.

Days delinquent calculations are done in Julian format. The following

example illustrates how days delinquent are calculated.

Past-Due Notices Based on Days Delinquent

On ARML13, you can enter days delinquent in the P/D DAYS 1 and P/D
DAYS 2 fields in order to have the system automatically generate past due
notices to customers.

=========================================================
============================

Interest Processing Overview

In CMS, several different types of records contribute to processing interest
on accounts. You can control the interest processing by establishing
Processing Control Tables, Logo records, Credit Plan Masters, and Interest
Tables that work in conjunction with each other.

The Role of Logo Records

An account’s PCT ID points the account to the identical ID on a Processing

Control Table that exists at one of the three processing levels in CMS:
system, organization, and logo. The PROC CONTROL LEVEL field on
page 14 of the Logo record determines the level of the Processing Control
Table that will be used by accounts in the logo.

Processing Control Tables

A Processing Control Table (PCT) is composed of PCT IDs and the

numbers of their associated Account Control, Service Charge/Fee,
Insurance, and Interest Tables. After setting up all of the Account Control,
Service Charge/Fee, Insurance, and Interest Tables that your institution will
be using, you can establish Processing Control Tables that will point
accounts, by means of their PCT IDs, to different combinations of these
tables, where the actual processing parameters exist.

Under each ID on the Processing Control Table are 12 Rate Table

Occurrence Indicators (RTOI 1 -12), where you can enter the numbers of
Interest Tables that you have already established. In this way, you can
associate up to 12 different Interest Tables with each individual PCT ID.

The Role of Credit Plan Masters

In the RATE TBL OCCUR (Rate Table Occurrence) field on the Credit Plan
Master (ARMC01), you enter a value from 01 to 12 to specify which of the
RTOI positions contains the number of the Interest Table to be used in
calculating interest on the plan.
In this way, an account with multiple credit plan segments can be subject to
multiple Interest Tables and, therefore, multiple interest rates. Each plan
on the account can have interest calculated differently because each Credit
Plan Master can point to a different RTOI on the Processing Control Table.

Other interest-related fields on the Credit Plan Master are covered in

Section 5 of this manual.

Assume that the account is participating in plan 80002 and that the RATE
TBL OCCUR on Credit Plan Master 80002 is “03.”

The Role of Interest Tables

Interest Tables contain the actual parameters for calculating interest on

credit plan segments. Interest Tables allow you to define the balance
subject to finance charges, when interest will begin accruing, the accrual
method, the rate type, and the percentage rate(s) to be used in the interest
calculation.

Assume that Interest Table 501, the Interest Table in the RTOI 3 position
on the Processing Control Table under ID “FL,” contains a fixed rate of
14%.

================================================

The Relationships Among the Records

LOGO RECORD

ORGANIZATION 800 LOGO 850

PROC CONTROL LEVEL ( L )

ACCOUNT BASE SEGMENT

ORGANIZATION 800 LOGO 850

ISSUANCE ID ( FL )

PROCESSING CONTROL TABLE

ORG 800 LOGO 850

ID FL

CURR

RTOI 3 501

INTEREST TABLE

ORG 800 LOGO 850 TABLE 501

RATE TYPE ( F )
RATE 1 ( 1400000 )

CREDIT PLAN MASTER

ORG 800 PLAN NBR 80002

RATE TBL OCCUR ( 03 )

The PCT ID on the Account Base Segment and the Processing Control
Level on the Logo record point the account to the same ID on a Processing
Control Table at the designated processing level.

At the same time, the Rate Table Occurrence on the Credit Plan Master
points the plan to a Rate Table Occurrence Indicator on the Processing
Control Table.

At the intersection of the ID and the RTOI on the PCT is the number of the
Interest Table in effect for all accounts with the ID that participate in the
plan. Note that the Interest Table must be at the same processing level as
the PCT.

Defining Interest Options

Flags to Include/Exclude B-N-P Components

In CMS, interest calculations need not be performed on the entire credit

plan balance. Using the flags at the top of the Interest Table, you can
specify which billed-not-paid components of the plan’s balance will
comprise the plan’s Balance Subject to Finance Charges (BSTFC).

Therefore, if your institution is prohibited from charging interest on interest,

you can exclude prior-assessed interest from a plan’s BSTFC when CMS
computes new interest on the plan. You can also set the flags to include or
exclude fees and services charges.

Interest Start Debit and Interest Start Credit

The INT START DB code determines when interest calculations will begin
on debit transactions. You can choose to have calculations begin on the
effective date of a transaction or on the posting date. Other values allow
you to begin interest calculations based on payment due date or statement
date. The INT START CR code determines when credit transactions affect
the calculation of interest.

Interest Next Statement

The INT NEXT STMT field controls how CMS processes interest on new
debits posted during a billing cycle. This field provides additional controls
beyond grace days processing. It is used to waive, charge, or defer
interest on new debits in specific circumstances. The circumstances occur
when:

• The cycle is the first cycle of a new account (the

beginning balance is zero)

• The cycle is a cycle in which an account reactivates after

a period of dormancy (the beginning balance is zero)

• The cycle is a cycle in which the customer pays in full (the

beginning balance is greater than zero but is paid in full during the
cycle).
For any value that you enter in the INT NEXT STMT field, the system will
test for either of these conditions:

• Whether the beginning balance of the cycle is zero

• Whether the beginning balance is greater than zero but is

paid in full during the cycle.

Depending on the value entered in this field, the test for beginning balance
and payment in full may be at the account or the plan level, and grace days
may be observed or ignored. Use the following guidelines when deciding
which value to use:

• If you want to waive interest on new debits in the

circumstances listed above, choose one of the following options: N,
A, P, B, or Q.

• If you want to charge interest on new debits in the

circumstances listed above, choose one of the following options: Y or
U.

• If you want to defer interest on new debits in the

circumstances listed above, choose one of the following options: D,
G, or R.

The “Understanding Interest Options” chapter of the CMS User’s Guide

contains descriptions and examples of these options.

Year Base and Accrual Method

The YEAR BASE code specifies the base number of days in the year to be
used in computing interest on plan segments subject to this Interest Table.

The ACCRUAL METHOD specifies whether interest will accrue on the plan
either daily or monthly. In additional to standard monthly accrual, CMS
offers a “monthly adjusted ending” option.

Using the daily accrual method, CMS updates the aggregate BSTFC and
accrued interest fields on the plan segment during each processing run. At
cycle close, the system bills the accrued interest to the account.
Using the monthly method, CMS accrues no interest on the plan segment.
At the cycle close, the system calculates the Average Daily Balance (the
aggregate BSTFC divided by the number of days in the cycle) and applies
the interest rate to it. The monthly accrual method requires a year base of
360 days.

Using the monthly adjusted ending method, CMS accrues no interest on

the plan segment. At the cycle close, the system calculates an “average
BSTFC” (the beginning principal balance minus cycle-to date debits) and
applies the interest rate to it.

Using the balance at month end method, CMS accrues no interest on the
plan segment. At the cycle close, the system takes the balance at the end
of the cycle and calculates the BSTFC and applies the interest rate to it.
This method requires a year base of 360 days.

When calculating interest, CMS uses predetermined factors. For the daily
interest method, the factor is based on the number 1 divided by the YEAR
BASE. For all of the monthly methods, the factor is based on the number 1
divided by the YEAR BASE and multiplied by 30.
The following table shows exactly how interest is computed using the
different combinations of accrual methods and year bases:

If interest is to be computed…

The formula is…

Daily with a 365 day year base

BSTFC x Interest % Rate x .0027397

Daily with a 366 day year base

BSTFC x Interest % Rate x .0027322

Daily with a 360 day year base

BSTFC x Interest % Rate x .0027778

Monthly with a 365 day year base

BSTFC x Interest % Rate x .0821918

Monthly with a 366 day year base

BSTFC x Interest % Rate x .0819672

Monthly with a 360 day year base

BSTFC x Interest % Rate x .0833333

Balance at month end with a 360 year base

BSTFC x Interest % Rate x .0833333

In CMS, the amount of interest assessed on a plan segment is not

determined by interest rate alone. You may have two or more Interest
Tables with the same rate on them. However, if their year bases and
accrual methods are different, the amount of interest assessed by each will
be different.
Rounding of Interest Calculations

Another influence on the exact amount of interest assessed by an Interest

Table is the rounding method specified in the INT CALCULATION field.
You can choose to round up or down, always round up, or forego rounding.

Rate Types

You can choose from among 5 different rate types, including interest-free
(zero rate).

F =

Fixed rate

A single rate is applied, regardless of the amount of the plan segment

balance

T =

Tiered rates

Multiple rates are applied based on plan segment balance ranges

V =

Variable rate

A base rate is applied, plus or minus a single variance, regardless of the

plan segment balance

U =

Tiered variable

A base rate is applied, plus or minus multiple variances based on plan

segment balance ranges
Z =

Interest-free

No rate is applied.

Fixed Rate

If you are using a fixed rate, enter the rate in the RATE 1 field on page 03
of the Interest Table. No other rate-related entries are necessary.

Tiered Rates

If you are using tiered rates, enter however many rates you will be using in
the RATE 1 – RATE 9 fields on page 03. Then enter the upper limits of the
plan segment balance ranges in the appropriate LIMIT1 – LIMIT8 fields on
page 03. You must also enter a value in the LIMIT INDICATOR on page
02 to indicate how the tier limits will be handled.

Variable Rate

If you are using a variable rate, enter the index number of the base rate in
the RATE INDEX TBL field on page 02. Then enter the VARIANCE
percentage in the RATE 1 line on page 03. Because the base rate will be
drawn from the Rate Index Table, the RATE 1 field itself must contain
zeros.

Tiered Variable Rates

If you are using tiered variable rates, enter the index number of the base
rate in the RATE INDEX TBL field on page 02. Enter however many
variances you will be using in the VARIANCE fields on page 03. Because
the base rate will be drawn from the Rate Index Table, the RATE 1 – RATE
9 fields must contain zeros. Enter the upper limits of the plan segment
balance ranges in the appropriate LIMIT1 – LIMIT8 fields on page 03. You
must also enter a value in the LIMIT INDICATOR on page 02 to indicate
how the tier limits will be handled.
Limit Indicator

This field instructs CMS on how to use the tier limits for tiered and tiered
variable rates. If you select option N, the system will apply a different
interest rate to each portion of the balance that falls into a tier range. If you
select option Y, the system will apply one rate based on where the total
balance falls in the tier ranges.

Example: The following example illustrates how the LIMIT INDICATOR

works. Assume that a plan segment has a balance of $2,500. Tiers have
been set up as follows:

Rate 1

1350000

Limit 1

00000000000001000

Rate 2

1150000

Limit 2

00000000000002000

Rate 3

0950000

Limit 3

00000000000003000

If the LIMIT INDICATOR is set to N, the system will apply a rate of 13.5%
to the first $1000 of the balance, a rate of 11.5% to the second $1,000, and
a rate of 9.5% to the remaining $500.
If the LIMIT INDICATOR is set to Y, however, the system will apply a rate
of 9.5% to the entire balance.

Controls Over Variable Rate Increases and Decreases

When you use a variable rate or tiered variable rates, the base rate is
located on a Rate Index Table that must be established and maintained
separately from the Interest Tables. Interest rates that result from applying
a margin of points to an index rate (such as the prime lending rate) are
termed the calculated or actual rates on the plan segments. These actual
rates will rise and fall as the base rate rises and falls.

The Rate Index Table is covered later in this section of the manual.

You can control the effects of increases or decreases in the base rate by
using the following fields:

CAP REDUCTION specifies the maximum number of points an actual rate

will be allowed to fall. CAP INCREASE specifies the maximum number of
points an actual rate will be allowed to rise. Use FLOOR RATE 1 and
CEILING RATE 1 to set minimum and maximum actual rates for plan
segments subject to the Interest Table. If you want to have two sets of
floors and ceilings based on a balance cut-off amount, use FLOOR RATE
2 and CEILING RATE 2 as well, and enter the balance amount in the
LMT1 field on page 02.

• The copybooks related to the print routines are –

AR20WS - Print work area

AR00WS - Dynamic sub-routine list

CCS301 - Date work area

CCS516 - Output system date

AR20PD - Procedure division copybook

ARPRINT - Report printing Program

• In Release 8.0, there are no changes to the coding

procedures

• The copybooks related to the print routines are –

AR20WS - Print work area

AR00WS - Dynamic sub-routine list

SS01WS - Date work area

SS16PD - Output system date

AR20PD - Procedure division copybook

ARPRINT - Report printing Program

VisionPlus 2.5

• Working storage copybook

• CCS301 Date work area

• Procedure Division Copybooks

• CCS503 Future date calculations

 • CCS504 Elapsed days calculations

• CCS505 Date validation (Gregorian)

• CCS506 Day of the week calculation

• CCS507 Gregorian to Julian date conversion

• CCS508 Julian to Gregorian date conversion

• CCS510 Back-date calculations

• CCS516 System date and time

• CCS518 Elapsed months/years calculation

• CCS520 Date validation (Julian)

VisionPlus(8.0 above)

• Working storage copybook

• SS01WS Date work area

• Procedure Division Copybooks

• SS03PD Future date calculations

• SS04PD Elapsed days calculations

• SS05PD Date validation (Gregorian)

• SS06PD Day of the week calculation

• SS07PD Gregorian to Julian date conversion

• SS08PD Julian to Gregorian date conversion

• SS10PD Back-date calculations

• SS16PD System date and time

• SS18PD Elapsed months/years calculation

• SS23PD Date validation (Julian)

 To use abend routine following copybooks need to be incorporated in
the program

Working Storage copybooks

• V+ Rel 2.57 and Prior

CCS302

• V+ Rel 8.0

SS02WS

Procedure Division copybooks

• V+ Rel 2.57 and Prior

CCS502

• V+ Rel 8.0

SS02PD

CCSABEND ( Vision 2.5)

Called in CCS502 copybook to display abend messages and in turn

call CCSCANCL program. This program is renamed as SSSABEND in rel
8.0
Direct Debit

Transaction controls for future-dated debits also pertain to direct debits

generated on a

number of days prior to the payment due date. For example, if a logo is set
up to generate

direct debits on a number of days prior to the payment due date (DD
PAYMENT FLAG on

ARML12 is P), the logo must allow future-dated direct debits to be

warehoused

(TRANSACTION CONTROL: POST DATED DEBITS on ARML12) for the

number of days that

will be assigned to accounts in that logo (DD REQUEST DAY on

ARMB06). Therefore, if a

direct debit transaction is generated with a future date greater than the
number of days

specified, CMS rejects the direct debit transaction.

If you decide to allow backdated transactions, you can manually change

the date on the

transaction to the posting date. Or, you can indicate the number of days a
transaction can

be backdated. The number of days specified can be calculated from the

last day of the

prior year, or calculated from the current date. If the transaction effective
date is a past
date greater than the number of days specified, CMS rejects the backdated
transaction.

Fraud transaction transfer

The fraud transaction transfer option on the Logo record (FRAUD XFER
field on ARML12)

controls whether CMS stops a transaction from being transferred for fraud
reasons. When

the FRAUD XFER field is 000, a transaction can be transferred at any time
for fraud reasons.

When this field contains a value of 001–999, CMS does not allow a
transaction to be

transferred for fraud reasons for the number of days specified from the
transaction posting

CMS 8.35 User Operations and Concepts Guide Logo Record Controls

November 2009 11–11

date. If a transaction is not prohibited from transfer, the transaction can be

selected for

fraud transaction transfer using the FRAUD TRANSFER FUNCTIONS on

ARTS01. If a fraud

transaction transfer is already pending, use of ARTS01 fraud transfer

function cancels the

transfer. The status of a transferred fraud transaction can be viewed using

the Transaction

Display (ARTD) or Online Statement History (ARSD) functions.

Direct debit and direct credit controls

In the Logo record, you can establish controls that determine how CMS
processes direct
debit and direct credit transactions for accounts in the logo. You can
indicate whether

CMS:

􀂉 Allows direct debit and direct credit processing for accounts in the logo
(DD/DC

ALLOWED on ARML12)

􀂉 Cancels direct debit processing when the account is at contractual

delinquency level

that causes cancellation (DD CYCLE DUE on ARML12)

􀂉 Cancels direct debit processing for excessive payment reversals

􀂉 Cancels direct credit processing when the account is at contractual

delinquency level

that causes cancellation (DC CYCLE DUE on ARML12)

􀂉 Applies interim payments to the direct debit payment amount before

generating the

direct debit

􀂉 Produces the direct debit transaction on the cycle date, the payment due
date, a

specific date, or a number of days prior to the payment due date (DD
PAYMENT FLAG on

ARML12).

, using the Payment Hierarchy controls, which are explained later in this

Direct debit payments

CMS provides direct debit processing for U.S. and international clients. In
the United
States, direct debit processing is governed by the regulations issued by the
National

Automated Clearing House Association (NACHA). To process direct debit

payments,

U.S. organizations must generate tapes in ACH format, which uses a nine-
digit routing/

transit number to identify the financial institution to receive prenotifications

(or prenotes)

and debit transactions for payments on an account. The tape format for
international

clients uses a ten-digit user-defined bank ID which identifies the financial

institution to

receive direct debits for payments on an account.

Direct debit processing requires parameters to be set up at the system,

organization, and

logo levels in CMS. Parameters also exist at the account level that enable
you to further

define how CMS processes direct debits for an account.

System controls for direct debit processing

To use direct debit processing in CMS, you must first select the ACH
participation option

in the PRENOTE field on the System Record (ARMS01). The options you
can enter in this

field are N (non-ACH participant, do not prenote) and Y (ACH participant,

prenote).

Organization controls for direct debit processing

After setting the PRENOTE field on the System record, you will need to set
parameters at

the organization level:

􀂉 Set the PRENOTE field on ARMO02 to indicate whether the organization

will process

direct debit transactions. The options you can enter in this field are N (non-
ACH

participant), Y (ACH participant), or Z (ACH participant, but do not prenote).

􀂉 Indicate organization overrides to the system-level parameters for direct

debit

processing by populating the bank-specific and user fields on ARMO02.

􀂉 Select the file format to be used for direct debit and direct credit
transactions in the

DD/DC INDICATOR field on ARMO10. The values you can enter in this
field are 0

(standard ACH format) or 1 (non-ACH format).

CMS 8.35 User Operations and Concepts Guide Payment Processing

November 2009 46–32

Logo controls for direct debit processing

The DD/DC ALLOWED field on ARML12 controls whether direct debit and
direct credit

processing is allowed for the logo. In addition to this field, you will need to
complete the

following logo-level parameters for direct debit processing:

􀂉 DD PAYMENT FLAG (ARML12)

􀂉 DD INTERIM PAYMENTS (ARML12)

􀂉 DD CYCLE DUE (ARML12)

􀂉 DD PAYMENT REVERSAL LIMIT (ARML12)

􀂉 NOM BILL OVERLIMIT (ARML12).

Each of these fields is described in the following paragraphs.

Direct debit/credit participation flag for logos

You must indicate whether each logo participates in direct debit or direct
credit

processing. Complete the DD/DC ALLOWED field on ARML12 by entering

one of the

following values:

N = Not participating in direct debit and direct credit processing

Y = Participating in direct debit and direct credit processing

A = Participating in direct debit and direct credit processing for prepaid

accounts.

Direct debit payment date flag

If you activate direct debit processing for a logo (DD/DC ALLOWED on

ARML12 is Y), you

must choose a date when CMS requests the direct debit payment.
Complete the DD

PAYMENT FLAG on ARML12 by entering one of the following values:

S = Generate the direct debit transaction on the cycle date

D = Generate the direct debit transaction on the payment due date

(Default)
R = Generate the direct debit transaction on a specific day of each month

P = Generate the direct debit transaction on a specific number of days prior

to

the payment due date.

If you select values R or P, you must identify the specific day of the month
(for value R) or

the specific number of days prior to the payment due date (for value P).
Enter this number

at the account level (DD REQUEST DAY on ARMB06) for each account
that participates in

direct debit processing.

For DD PAYMENT FLAG values S and P, CMS warehouses the payment

transaction until the

effective date. Upon reaching the effective date, CMS posts the transaction
to the

customer’s account. For DD PAYMENT FLAG values D and R, CMS posts

the transaction to

the customer’s account immediately.

􀀕 When the DD PAYMENT FLAG on ARML12 is S, CMS does not use

the DD INTERIM PAYMENTS option on ARMB06.

CMS 8.35 User Operations and Concepts Guide Payment Processing

November 2009 46–33

Apply interim payments to the direct debit payment amount

Use the option DD INTERIM PAYMENTS on ARML12 to indicate whether

interim payments
made to the account between the cycle date and the transaction generation
date are applied

to the direct debit payment. The values for this field are:

0 = Do not apply interim payments (Default)

1 = Apply interim payments to the calculated payment prior to generating a

direct debit transaction.

This value defaults to the Account Base Segment (ARMB06) but can be
modified at the

account level.

Cancellation of direct debit processing for cycle due delinquency

You can indicate on the Logo record the contractual delinquency level at
which CMS

automatically cancels direct debit processing for an account. For example,

if you want

CMS to cancel direct debit processing for an account that is 90 days or

more delinquent

(cycle due code 5), type 5 in the DD CYCLE DUE field on ARML12. Any
direct debit

cancellations are reported on the DD/DC Journal report (D12).

􀀕 At any time, you can manually initiate the cancellation of the direct

debit process by changing the DD PAYMENT value on ARMB06 from

1 (minimum payment), 2 (customer-nominated, past amounts

included), or 7 (customer-nominated, past amounts not included) to

a value of 0 (not used). This cancels the direct debit immediately;

CMS will bypass direct debit processing for the account in the next
batch run.

Cancellation of direct debit processing due to excessive payment

reversals

You can indicate on the Logo record the limit at which CMS will cancel
direct debit

participation due to excessive payment reversals (logic modules 031 or

032). To do this,

enter a value in the DD PAYMENT REVERSAL LIMIT field on ARML12.

The values are:

0 = Do not cancel participation due to payment reversals. (Default)

1–9 = If the DD PAYMENT REVERSAL COUNTER on the Account Base

Segment is

equal to or greater than the value in this field, cancel direct debit

participation. Direct debit cancellations print on the DD/DC Journal

report (D12).

CMS uses this field in conjunction with the DD PAYMENT REVERSAL

COUNTER on the

Account Base Segment (ARMB06).

Example:

An account is in a logo that has the DD PAYMENT REVERSAL LIMIT

(ARML12) set to 8. On

generation day for the direct debit, if the DD PAYMENT REVERSAL

COUNTER (ARMB06) is

equal to or greater than 8, CMS changes the DD PAYMENT flag on

ARMB06 to 5 (canceled)

CMS 8.35 User Operations and Concepts Guide Payment Processing

November 2009 46–34

via batch processing. The current direct debit transaction is included on the
DD/DC file

but further direct debit processing is canceled for the next cycle.

Overlimit payment calculation

The NOM BILL OVERLIMIT field on ARML12 allows you to control how
CMS determines the

direct debit payment amount when a nominated payment is in effect (direct

debit

processing is active) and there is an overlimit amount on the account. The

values are:

0 = If the DD PAYMENT (ARMB06) is 2, CMS bills the nominated payment

amount or the sum of the system-calculated minimum payment amount

plus the overlimit amount, whichever is less.

1 = If the DD PAYMENT (ARMB06) is 2, CMS bills the nominated payment

amount plus the overlimit amount.

2 = If the DD PAYMENT (ARMB06) is 2, CMS bills the nominated payment

amount or the sum of the system-calculated minimum payment amount

plus the overlimit amount, whichever is greater.