Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means, for any purpose, without
T24 Country Model Bank
Canadian Model Bank
Scope: Card Management
Document History
Version Date Author /
Changed By Status Change Description
0.1 02/06/2014 Kundanmal Soni Initial
Contents
1
PURPOSE OF THIS DOCUMENT ... 4
2
PRODUCTION ENVIRONMENT ... 5
3
DESCRIPTION ... 6
3.1 Functionality ... 6 3.2 T24 Module support ... 7 3.2.1 Necessary T24 Modules ... 8 3.2.2 Supported T24 Modules ... 8 3.3 Dependencies ... 83.3.1 Necessary other components ... 8
3.3.2 Exclusions ... 8
3.4 Online Help Text ... 9
3.5 User Manuals ... 9
3.6 Multi book / Multi Company ... 9
3.7 Processes... 10
3.8 Special remarks ... 13
4
FUNCTIONALITY... 14
4.1 Business Need ... 14
4.2 Cross Functional Diagram ... 15
4.3 Development Overview ... 15
4.4 Functionalities Covered ... 22
5
SET UP AND INSTALLED ELEMENTS ... 26
5.1 Routines and set up ... 26
5.1.1 Routines ... 26
5.1.2 Routine Screen Sample ... 26
5.1.3 Tables... 30
5.1.4 Local References ... 30
5.2 Parameters ... 32
5.3 Screens, Reports and menu’s ... 32
1 Purpose of this Document
This document describes the scope of the Card Management, a module in Canadian Model Bank. This module allows the bank to produce debit card and maintenance operations include starter card inventory, card parameterization, card maintenance, card reordering, card order file generation, assigning cards, card updates, maintaining information about accounts account assess through different channels and card purging. The Card Management belongs to a specific T24 release and operating platform mentioned in paragraph 2.
2 Production Environment
The current version of Card Management in the Canadian Model Bank is based on the below version of T24.
Component Server / OS
T24 Runtime R13
OS Platform Windows Server 2003/2008 (64 bit Only)
RedHat Linux AS5 (AS5 only)
AIX v5.3
AIX v6.1
Solaris 10 (Sparc only)
Solaris 10 x86-64 HPUX Itanium2 11.31 V3 Database Jbase\TAFC TAFJ Oracle DB2 SQL
Web Server AIX
3 Description
3.1 Functionality
Debit card production and maintenance operations include starter card inventory, card parameterization, card maintenance, card reordering, card order file generation, assigning cards, card updates, maintaining information about accounts account assess through different channels and card purging. Starter card concept is used to provide the member with active debit cards as soon as they open an account or require a replacement card.
CAF files currently generated:
Cards.txt Accounts.txt CardAccounts.txt AccountBalances.txt Statements.txt AccountOverrideLimits.txt CardOverrideLimits.txt Customer.txt CustomerAccounts.txt
The above mentioned files are generated based on the Threshold Connector Specification standard version 3.0.02.
The FHM messages are generated:
Issue New Debit CARD Cancel Debit Card Add New Account Close account
Add new Membership to the joint relation Remove Membership from the relation
Card Ordering and Inventory Management:
Cards can be ordered by Branch and by Card type.
Minimum quantity can be configured for automatic reorder.
Automatic reorder happen based on Expiry date of the Card as well. Card will be available for Issuance once physically available in Branch.
Card Issuance and Management:
The following is the list of available card status in T24 which defines the different status of the Card issuance/Usage. These values are defined in the CARD.STATUS table.
New Order – Status is updated when a new Card Order is initiated. Ordered – Status when Card Order to Card Production Vendor Available – Status when physical Card is available in the branch Issued – Status when Card issued to the Member
Active – Status updated when the Card used in any device connected to switch. Cancelled – Status Updated when Cancelled in branch
Damaged – Status Updated in Branch
Lost/Hot – Status updated when complained Lost/Hot through IVR or in Branch.
3.2 T24 Module support
Since this development is based on the module in T24 there is no further dependency on the modules used. Hence all modules are supported.
3.2.1 Necessary T24 Modules
The Card Management functionality offered by the Canadian Model Bank is supported with
the following modules.
T24 Module Remarks
Customer Versions created For CAMB will be used
Accounts Versions created for CAMB will be used
CARD.ISSUE Cards get produced in CARD.ISSUE
with status ORDERED.
CARD.STATUS To set status of the card
CARD.TYPE To set type of card
3.2.2 Supported T24 Modules
N A
3.3 Dependencies
3.3.1 Necessary other components
N A
3.3.2 Exclusions
3.4 Online Help Text
The following are the tables that are having online help text:
CARD.ACCESS CARD.FORMAT CARD.INTERFACE CARD.ORDER CARD.LIM.DEF CARD.ACS.DEF CARD.ACCESS CARD.ISSUE
3.5 User Manuals
Process oriented user guides explaining the business workflow with the standard parameterization are available. Screen fields are explained as long as they are triggering Country specific functionalities or they are required to control the business process. Detailed explanations, domains and validation rules are provided.
3.6 Multi book / Multi Company
The Card Management is enabled to be set up as a multi-company environment with one head quarter and with multi-booking enabled. One default branch is provided as part of the standard parameterisation. Further branches and books can be defined by the bank as required.
3.7 Processes
Starter Cards ordering process
Start
If the starter card falls below
the minimum
Check Branch card parameter file
for number of cards to be
produced
Create new cards with PAN number automatically generated based
on the BIN information
Change the Card Status to “New Order” Card record written in card order file End No Yes
Based on the information available in starter card
inventory file
Card Status changed to “Ordered”
Card order file generated Member Cards are not
PINed
Assigning starter card: Start Customer requests for a card A Starter card is transferred from dummy CIF to Customer CIF
All Accounts which has rights to individual access
are defaulted to the card
Card is PINned
Card is used for the first time in the
ATM / POS
PIN offset updated
in the Card record End Card status
changed to “Active” Card status is automatically
changed to “Issued”
The message contains the PIN offset
Reordering card process:
Start
Cards with status “Issued” or “Active”
If expiry date less than current date plus the number of days
in the “Days Advance” Field
Cards with status as “Issued”
Expiry date = Current expiry date
+
“Card Life” in system record
Cards with status as “Active”
Reordered card file with name, PIN offset etc.. All other setting should be same
as the original card
Stop Yes No Yes No No Yes
Change card status as “Issued”
Card Order file includes cards created manually
3.8 Special remarks
No
4 Functionality
4.1 Business Need
Canadian Layer has debit cards that can be used at all ATMs and for POS purchases in Canada and also all over the World through Maestro network for International POS and CIRRUS for international ATM transactions. Debit card production and maintenance operations include starter card inventory, card parameterization, card maintenance, card reordering, card order file generation, assigning cards, card updates, maintaining information about accounts account assess through different channels and card purging. Starter card concept is used to provide the member with active debit cards as soon as they open an account or require a replacement card.
Card numbers (PAN number) are also used for access to Internet Banking (Member Direct) and Interactive Voice Response (IVR) banking.
The use of a card record for any one of the self-service channels (ATM & POS, Member Direct, and IVR) does not mean that the member wishes to use it in any other channel. E.g. a member requests a card for ATM & POS use. Access to Member Direct and IVR should not be automatically created. These channels are activated only on specific request from the member.
All card records must be attached to a CUSTOMER record. The CUSTOMER record must be an individual or a business entity only and not a “Container” type CUSTOMER record. It is very important for bank that the Card record and PAN uniquely identifies the individual or the business entity that is accessing the banking system using a card or a PAN number. Multiple accounts can be attached to each card record. The accounts can be RSP / RIFF accounts attached to the CUSTOMER record that the card is attached to or any “Container” CUSTOMER accounts in which the card’s CUSTOMER record is included as an owner.
Requests for new card orders can come from three areas; bank staff creating a new card record through T24 application (manual ordering), the starter card inventory system (see starter cards) and card renewal process (Reordering of cards).
4.2 Cross Functional Diagram
card mgmt-CFD.docx
4.3 Development Overview
Card Interface
1. Card interface have information about the interfaces that can be used for the card. 2. The online limit, offline limit, ONUS deposit hold days for cash and cheque, OFFUS
deposit hold days for cash and cheque, ONUS deposit threshold amount for cash and cheque, OFFUS deposit threshold amount for cash and cheque, transaction codes for different kind of deposits etc… should be stored in the card interface level
Card Type
1. Need to define and maintain card types
2. Need to define and maintain the BIN information based on card types
3. Card life, number of days before the card is to be reordered, auto reorder indicator etc… details are maintained in the card type file
Card Order
1. Card order parameter file is used to maintain the inventory card details of starter cards held in branches. Each branch maintains its own card order file
2. The following information should be stored in the Starter card inventory tables a. Card Type
b. Branch detail
c. Member number for Starter Cards, the member number should be unique (For each branch a CUSTOMER should be created for the starter card. The starter card customer requires a “Container” type customer to which a savings account and a current account are attached. These two accounts will be attached to each starter card that is created through starter card order process)
e. Minimum number of cards remaining in inventory before auto reorder f. Last date on which card is ordered
g. Number of cards remaining in the system
h. Order indicator which is used to specify whether cards are ordered or not
Card Status
1. Need to define, maintain and link the card status with card records
1
New Order No ATM or POS activity allowed
2 Ordered No ATM, POS, Member Direct and IVR
activity allowed
3 Available Card is available for issue
4 Issued ATM, POS, Member Direct and IVR
activity allowed
5 Active Activity allowed
6 Cancelled No ATM or POS activity allowed
Customer Grouping Default (CARD.LIM.DEF)
Defaulting of the value to the card records are basically from two levels. The values defaulted are from card interface (CARD.INTERFACE) and customer grouping default (CARD.LIM.DEF) tables. In customer grouping default table the information for below fields are maintained for each customer group. These set of default values can be grouped based on Industry and sector.
1. These defaults must apply both when a card record is first created and when a card record is assigned from the “Starter Card Customer” to a new CUSTOMER. The defaults in the latter case being derived from the new CUSTOMER the card record is being attached to.
e. Deposit threshold amounts for cash and cheque for ONUS and OFFUS transactions
f. Number of days that deposits are held for cash and cheque for ONUS and OFFUS transactions
Account and Product access function defaults
The Account access function defaults (CARD.ACS.DEF) are defined to maintain the account access flag and product access flag defaults. In this table the access flag information are maintained for each account type and product type.
Card Issue
1. In T24 the PAN will also be used to access the IVR (Telephone Banking system) and Member direct (Internet Banking), apart from ATM and POS
2. PAN number must remain the same for bank members when the card renews 4. The following information should be stored in the card files
a. Type of card
b. Card status need to updated in the card record c. Expiry date of the card
d. PIN offset which will be the part of the incoming ATM and POS ISO message should be captured and updated in the card record
e. Number of PIN retires information need to stored in the card record f. PIN delivery option
g. Card delivery option provides mailing option through ‘C’ for Courier or ‘F’ First class mail
Existing starter card records, accounts and branch inventories must be converted from the existing system. This process is part of the migration activity
Card Access information
1. Card access file should contain the following information
a. Number of days a deposit will be held if deposit made at a bank machine and number of days held if deposit made at an Exchange machine for cash and cheque. Threshold amounts for the amount to be held on each deposit for ONUS and OFFUS transactions for cash and cheque
b. online and offline limits for the respective interfaces like ATM and POS
c. Which accounts can be accessed at through interfaces and functions that are allowed at the ATM, POS, member direct and IVR for this Card. The following are the list of account access flags BI – Balance Inquiry WD – Withdrawal DP – Deposit TO – Transfer Out TI – Transfer In BP – Bill Payment MS – Mini Statements
d. There can be only one chequing and one savings account per card for accessing at POS terminals and these details should be stored in the card record with the help of network setting information
Starter cards and Re ordering of Cards
1. If the starter card in the inventory falls below the set minimum, the banking system should generate the new card records
2. The Process of starter card production is scheduled as weekly. Bank should have the option to change the frequency of starter card production process.
3. The number of new starter card generated is based on the information from the branch card order file. Information maintained in card order file is mentioned in Card order part of Requirement specification section of this document.
4. Card number should be the PAN number and T24 must automatically generate the card number according to the following rules:
a. Each PAN number consists of a BIN number that is the same for all cards of the same type + a sequential number generated by the banking system + a Mod 10 check digit calculated on the whole card number
b. Bank member card BIN is 581809053 followed by a 6 digit sequential number and a final check digit using Mod 10
c. Note: The portion of the PAN number after the BIN is constructed differently by different financial institutions. Some local bank include a sequence number / issue number
5. The Card number is generated based on the information of BIN and the sequential number that is stored in the system
6. New card orders are from two sources, the new card records created automatically and the records created manually by the tellers. The new cards which are created automatically should be a separate file from the new card created manually by tellers. 7. Cards are separated as starter cards created automatically by the system and the new
cards created manually by the teller based on the mode of delivery.
8. Expiry card records includes records with status as “Issued” , “Available” or “Active” and the cards with expiry date less than the current date plus the number of days in the “Days in advance” fields
9. Manual process of ordering new cards due to loss, compromise, etc...
10. Cards which are reordered may or may not be pre pinned based on the PIN Envelope field
11. Card order file for member card going to G&D is generated 12. ASCII file format is used for the following orders:
b. auto re order cards
c. re order cards as per request by teller (for damaged cards)
d. order a new card as per request by teller (in the event of deliver the card to the client)
13. Frequency of reordering starter cards for bank is weekly but could be changed in the future. Bank should have the option to change the frequency.
14. Name on cards for business can be two lines
15. Once the customer requests for new card a card is transferred from dummy CIF to the respective Customer CIF
16. The PAN number can only be associated with one customer record i.e. it must be a single ownership record. The card record and the PAN uniquely identify the individual or business entity that is accessing the banking system using the card.
17. Cards from any branch can be assigned to a customer of any branch
18. Multiple accounts from multiple “container” CUSTOMERS can be attached to a card provided that the CUSTOMER to which the card is attached is included in the “container” CUSTOMER records as an owner
19. Only specific account and Product types can be accessed through the card. System need to control which accounts a staff can associate with a card. The account types and product types that can be associated with the card along with the flag are to be defined in the accounts and product access function table (CARD.ACS.DEF)
20. When the customer is attached to the card, all the accounts, in which the card’s CUSTOMER record is included as an owner are defaulted to the card. All the accounts like savings, chequing and RSP / RIFF accounts attached to the customer record that the card is attached to or any “Container” customer accounts in which the card’s customer record is included as owner.
21. The PIN offset which is stored in the card record should be used in card reorders 22. Reordered card have customer name on them
23. Controls must be there in T24, so that it is not possible to resend the card production file again
24. Card order is a batch process that is scheduled to run in COB 25. Card is delivered to the card suppliers through FTP sites
Card Management
1. Limit, hold status and other changes should be updated real time. These changes to the card record will generate a “From Host Maintenance” record to update the ATM / POS switch card file for the account changes.
2. Automated updates to system card records as a result of opening and closing accounts that qualify for access at an ATM, POS, Member Direct and IVR. These automated changes to the card record will generate a “From Host Maintenance” record to update the ATM / POS switch card file for the account changes.
3. New and reordered cards are updated into the banking system and the information should be send to the ATM switch (From Host Maintenance [FHM]).
4. Branch staff need to update the cards on real time based on the request from the members
5. Mass card updates are done for cards with select parameter settings and card status. E.g. online limits for all cards in a specific category may change
6. The mass card update process will send real time FHM message with details like online / offline limit, hold information etc…, ensure that this process will not block other online card maintenance functions from using the FHM channel to update the switch
7. Only senior admin staff should have access to the mass card update function
8. Maintenance done through the mass card update function should update the banking system card records and also the ATM switch through FHM
9. Any card maintenance changes done on card records that affect the online, offline limits and hold days should be compared with system standards for industry codes. Overrides should be raised for any difference in updating the standard fields of the card records 10. Batch process like mass card updates should not raise the overrides
11. The “mass card update” FHM card updates have low priority when compared to individual card updates from end users
12. Card with status as cancelled are removed from system once in a month based on the purge days mentioned in card maintenance record
4.4 Functionalities Covered
Card Parameters
a. Storing and maintaining inventory card details of starter cards b. Storing and maintaining card interface details
c. Standard card status file can be used, but the predefined records in card status file cannot be altered. Defining, Grouping and Maintaining System Card parameter details based on industry and sector. The details mentioned here are defaulted to the card issue and card access records
d. Defining and Maintaining the BIN information details for generating the PAN e. Generation of PAN number according to the rules defined by bank
f. Additional information for the card type can be accommodated using local reference fields
g. Additional information for card records can be stored with the help of local reference fields
h. Access flags for accounts to indicate the type of access available through ATM, POS, Member direct and IVR need to defined and maintained
i. When performing mass card updates, what is the minimum number of records should be selected to update the switch using the CAF update. If less number of records are selected then update the switch through FHM
Starter Cards ordering process
a. Based on branch card order file and if the starter cards falls below the minimum, system should generate the new card records
b. Starter cards created automatically by the system should be a separate card order file from the new cards created manually by the teller
c. Generate PAN number of the card according to the rules defined by bank d. The settings for the new card records are defaulted from the card default table e. Once the Card is written to the Card Order file, card status is changed to “Ordered” f. A card order file with new card records is created for Member cards going to G&D g. ASCII file format is used for starter card files and reordering card file.
Card Parameters
j. Storing and maintaining inventory card details of starter cards k. Storing and maintaining card interface details
l. Standard card status file can be used, but the predefined records in card status file can not be altered.
m. Defining, Grouping and Maintaining System Card parameter details based on industry and sector. The details mentioned here are defaulted to the card issue and card access records
n. Defining and Maintaining the BIN information details for generating the PAN o. Generation of PAN number according to the rules defined by bank
p. Additional information for the card type can be accommodated using local reference fields
q. Additional information for card records can be stored with the help of local reference fields
r. Access flags for accounts to indicate the type of access available through ATM, POS, Member direct and IVR need to defined and maintained
s. When performing mass card updates, what is the minimum number of records should be selected to update the switch using the CAF update. If less number of records are selected then update the switch through FHM
Assigning Started cards
a. When the customer requests for a card, a starter card should be transferred from dummy CIF to the respective Customer CIF
b. When the customer is attached to the card, all the accounts which are associated with the customer are also associated to the card.
c. Information related to online limit, offline limit, Hold days and hold amounts for ONUS and OFFUS transactions for cash and cheque are defaulted from the respective customer group file. If the customer does not falls under any of this grouping then the values are defaulted from the respective card interface record
d. The product and account access and access flags for the accounts are set
e. When the card is issued to the customer, i.e. when the card is moved from dummy starter card CIF to the respective customer CIF. The card status should be changed to “Issued” automatically
f. For member cards the member must PIN the card in the branch
g. Once the new card is put in the ATM and the PIN number is entered, the card status should be changed to “Active”
Reordering Card Process
a. Expiring card order includes cards with status “Issued” or “Active” and the cards with expiry date less than the current date plus the number of days in the “Days in Advance” field
b. Manual process of ordering is due to loss, compromise, etc…
c. Manual process of reordering is due to card been damaged.
d. PIN offset which is stored in the card record should be used in card reorders e. The status should not be changed for Member cards with status as “Issued” and
expiry date less than current date plus the “Days in Advance” field. The expiry date should be changed to current expiry date plus the “Card life” in the system record
f. The status should be changed to “Issued” for Member cards with status as “Active” and expiry date less than current date plus the “Days in Advance” field.
g. Records with mailing option of “C” Courier should be changed to “F” first class mail after Writing the record to the Card order file
h. Records with PIN envelope option of “Y” (Yes) should be changed to “N” (No) after writing the record to the card order file
i. All other setting for reordered cards should be same as the original card including the PIN offset.
j. The expiry date are always set to last day of month
k. Reordered cards should have their names on them
l. Card order process is weekly and could become a daily function
Card Management
a. Updating limit information, Hold status and other changes at real time
b. Automatic update to system card records as a result of opening and closing of accounts or products that are associated with the card
c. Card from any branch can be assigned to members of any branch d. Multiple accounts can be attached to a card
e. Mass card updates are done for cards with select parameter settings and card status. e.g. All cards which have an ATM online limit of $505.00 could be updated to have ATM online limit of $605.00
f. Card with status as “Closed” are not updated
g. Maintenance done through the Mass card update function should update the banking system card records and also the switch through FHM or CAF update. If the number of records are high (in the parameter file a field will be provided to indicate the minimum number records to be selected to perform CAF update) then the switch will be updated by the CAF file (as specified in the ATM FS document), otherwise it will be updated through FHM
h. Card maintenance changes like changing limit, hold status should be compared with system standard records, If there is a exception overrides should be raised.
i. Mass card updated FHM card updates have low priority when compared to the individual card updates from end users
j. Mass card updates frequency is ad hoc
k. Removing of card records with status as “Cancelled” from the system once in month based on the purge days mentioned in the card maintenance file
5 Set up and installed elements
5.1 Routines and set up
5.1.1 Routines
Routine Name
Called from
Remarks
CARD.COB.NEWORDER CARD.ORDER BATCH ROUTINE
CARD.COB.REORDER.LOAD CARD.ORDER BATCH ROUTINE
CARD.COB.REORDER.SELECT CARD.ORDER BATCH ROUTINE
CARD.COB.EXTR.ORD.FILE CARD.ACS.DEF BATCH ROUTINE
CARD.COB.EXTR.ORD.FILE .LOAD CARD.ACS.DEF BATCH ROUTINE
CARD.COB.EXTR.ORD.FILE.SELECT CARD.ACS.DEF BATCH ROUTINE
CARD.ARCH.CANC CARD.ISSUE BATCH ROUTINE
CARD.ARCH.CANC.LOAD CARD.ISSUE BATCH ROUTINE
CARD.ARCH.CANC.SELECT CARD.ISSUE BATCH ROUTINE
CARD.V.ALLOT.CARD.CUS CARD.ISSUE INPUT ROUTINE
CARD.ORDER.MANUAL CARD.ISSUE AUTH ROUTINE
5.1.3 Tables
Files created Remarks
CARD.ACCESS CARD.ACCESS records get created when a card is
issued to a new customer with status as issued. Account of the customer gets populated both in CARD.ISSUE & CARD.ACCESS
CARD.FORMAT This template holds different formats of card like
commercial and personal
CARD.INTERFACE This table is used to define the interfaces that can be accessed with the card.
CARD.ORDER Order/Reorder cards in bulk using CARD.ORDER table.
CARD.LIM.DEF The account and product access flags are defaulted
from the respective account type and product type grouping
CARD.ACS.DEF The account and products types that are allowed to
link to the card records and its respective access flags are defined here
CARD.ACCESS Card access file should contain the information like
card status, account access, access flags, limits, holds etc
CARD.ISSUE The information like card status, issue date, expiry
date, card holder, account number etc will be held by this template.
5.1.4 Local References
Application Local Ref
CARD.ISSUE CAMB.INTF.ALLOWED
CARD.ISSUE CAMB.INTF.PAC
CARD.ISSUE CAMB.INTF.PAC.DEL
CARD.ISSUE CAMB.INTF.CARD.DEL CARD.ISSUE CAMB.CUSTOMER CARD.ISSUE CAMB.CARD.FORMAT CARD.ISSUE CAMB.CARD.SEQUENCE CARD.ISSUE CAMB.ORDER.DATE.TIME CARD.ISSUE CARD.TYPE CAMB.AUTO.REORDER CARD.ISSUE CARD.TYPE CAMB.AUTO.REORDER CARD.TYPE CAMB.EXTERNAL.ID CARD.TYPE CAMB.MAX.RETRY.PAC CARD.TYPE CAMB.SEQUENCE CARD.TYPE CAMB.ID.FOR.CD.POS CARD.TYPE CAMB.ID.FOR.CD.LEN CARD.TYPE CAMB.ID.FOR.CD.VAL CARD.TYPE CAMB.CD.POSITION CARD.TYPE CAMB.CD.INS.OR.REP CARD.TYPE CAMB.CD.RTN CARD.TYPE CAMB.ID.MIN.LEN CARD.TYPE CAMB.ID.MAX.LEN CARD.TYPE CAMB.INI.CARD.LIFE CARD.TYPE CAMB.INI.CARD.RENEW CARD.TYPE CAMB.NXT.CARD.LIFE CARD.TYPE CAMB.NXT.CARD.RENEW
CARD.TYPE CAMB.PURGE.FREQUENCY
5.2 Parameters
The Card Management module comes with a set of already filled static data tables as part of the pre-parameterisation.
Parameter tables
Description
CARD.ACCESS CARD.ACCESS records get created when a card is issued to a new
customer with status as issued. Account of the customer gets populated both in CARD.ISSUE & CARD.ACCESS
CARD.FORMAT This template holds different formats of card like commercial and
personal
CARD.INTERFACE This table is used to define the interfaces that can be accessed
with the card.
CARD.ORDER Order/Reorder cards in bulk using CARD.ORDER table.
CARD.LIM.DEF The account and product access flags are defaulted from the
respective account type and product type grouping
CARD.ACS.DEF The account and products types that are allowed to link to the card
records and its respective access flags are defined here
CARD.ACCESS Card access file should contain the information like card status,
account access, access flags, limits, holds etc
CARD.ISSUE The information like card status, issue date, expiry date, card
holder, account number etc will be held by this template.
