Please enable JavaScript.
Coggle requires JavaScript to display documents.
EMS - Embossing Management System (Stages of the process (4.Cards…
EMS - Embossing Management System
Stages of the process
4.Cards embossing
At bank branches on installed printers
Desktop printers (e.g. models DataCard 150i, DataCard 280, DataCard 450) are connected directly to users’ hosts, thus client application should interact directly with them
Direct embossing
(on desktop printer) means that embossing operator’s client application directly generates commands for embossing cards and traces printer response on embossing status
Batch printers (e.g. DataCard 9000) are industrial machines able to emboss cards faster and in larger volumes. They can not be controlled from user host. Users should be able to generate embossing files containing data for embossing cards automatically for them
Indirect embossing
(on batch printer) requires generating hand-off files of specified format that should contain embossing tasks. These files should have special names characterising cards data type they contain and should be saved in different folders according to bank branches, then they should be transferred to printer for embossing. Printer response should be traced by users and than entered in client application manually by embossing operator
Outside the bank at outsourcing company (referred to as Rosan)
Rosan embossing
management logic is similar to indirect embossing: users should be able to select cards and generate hand-off files of specified format to be passed to Rosan system. Compared to in-house embossing, Rosan embossing files should be stored in separate folder and should have some additional fields. Tracing results of embossing at Rosan should be done manually similar to indirect embossing or automatically by uploading Rosan Issuing hand-off that Rosan system generates
Automated CDU embossing and dispatch process
means that embossing and card delivery processes work automatically. Host send handoff file, EMS process the handoff file, creates event and gets list of files, calculates value of field for records, performs processing records, perform processing for eSMS, merges pack according layouts, generates handoff files for C
W,
Corp and AU units. After that EMS begins the process of issue, pass files. After pass file creates Delivery Report 1 file for CSE. CSE genereate Feedback reports 1, 2 and 3. Also EMS can generate Delivery Report 2 and Delivery Report On-demand.
5.Plastic stock managing
Stocks classification by functionality
All the
non-storage
stocks are either
embossing
or
non-embossing
.
Embossing
stocks are stocks with printers that are used mainly for embossing cards.
Non-embossing
non-storage stocks may be used for blank plastic transfer and temporarily storing smaller quantities.
All the stocks are either
Storage
or
non-storage
.
Storage
stocks do not have embossing printers installed and are used for keeping large blank plastic inventory, ordering plastic from outside vendors etc.
Type of Stock relations
Supervisor
Each Stock should have a supervising Stock that should be authorised for checking and approving of certain actions
Auxiliary.
Each embossing stock should have an auxiliary Stock that should be used in case embossing is impossible at the stock. 2 Stocks can not be auxiliary to each other
Storage
.Each non-storage Stock should be related to a Storage as a default blank plastic supplies source. Storage stock should be set automatically as the closest upper-level Storage Stock in parent-child hierarchy
Parent - Child.
Each stock (except top-level Moscow Data Centre Storage) should have one parent Stock
The following operations to blank plastic should be performed in EMS at stock:
plastic transfer - is a physical movement of certain amount of certain plastic types from one Stock to another
release for embossing and receipt of unused plastic
inventory reconciliation
6.Cards dispatching
Before actually delivering embossed plastic cards to customers, they may become subjects to the following operations:
Embossed cards physical destruction
Emboss cards loss
Embossed cards transfer from one branch to another
Discover lost cards
Receive embossed Rosan cards
2.Data for cards processing in Singapore and resending to Citi Russia
Both credit and debit class cards can be issued in 2 ways:
Regular cards issuing process implies that data is received from Singapore periodically in bulk in hand-off files of specified format. Than it should be checked and approved before embossing. Thus, this way is relatively slower. This type of cards processing is referred to as “off-line”.
For some cards urgent issuing may be requested. Passing bulks of cards data in hand-off files and thorough checking procedures are too slow for this matter. Thus, another system is used: data for each card is received from Singapore via EXTRA! system in TCP messages on specified ports as soon as it is ready (not in bulks). Such data should be checked more briefly before actual cards can be embossed. Such type of card data processing is referred to as “on-line”. On-line processed cards are always non-photo.
7.Delivery tracking
Courier delivery
Direct customer pick-up
1.Client application acceptance at the front end and sending data to Citi Singapore
Issuing process for all cards involves sending requests to Citi Singapore division and receiving cards data for embossing from Singapore. All cards are embossed in local division and branches.
3.Data for cards importing, interpreting, checking and approval
Cards data upload and interpreting:
for off-line cards: from records in hand-off files received from Singapore host
for on-line cards: from messages via TCP protocol received from Singapore
Cards data checking: automated and by user. The following checks are required:
data completeness checks, i.e. all the required data was imported
data consistency data check, i.e. data is in accordance with EMS dictionaries
Users should be able to edit certain cards data fields and EMS dictionaries in order to ensure all checks run OK make cards with mistakes available for embossing.
Cards data approval:
for off-line cards – manual by authorised user
for on-line cards – automated by EMS
Type of plastic cards
Banking cards
Debit cards
- banking card normally not allowing the holder to pay more than he actually deposited.
Debit cards data is processed in a separate system as its issue does not require client’s credit application.
VIP
Main
Primary
Additional
Secondary
Credit cards
#
- letting users buy goods and services beyond what he actually deposited into his banking account with an obligation to repay the debt and interest in future. Credit card is a form of banking credit to individuals.
(Credit card processing starts within a separate credit application system (NAS), as additional checks of client’s financial solvency are required.)
VIP
Main
Primary
Additional
Secondary
Non-banking cards
Priority pass cards - non-banking card that provides some benefits, discounts etc. for certain goods and services. Holder can not pay for goods or services with non-banking card, he can not deposit to or withdraw money from it either. Priority pass cards are not issued separately on their own. They are always an addition to a banking card (credit).
(So, there is no separate system for processing Priority pass cards, they just need to be embossed together with certain types of credit cards)
Functional solution
According to business requirements EMS is aimed for automation of the following processes:
Cards dispatching
Cards data checks
Plastic stocks management
Cards embossing
As can be seen from graph, there are 3 core card issuing process stage to be realized in EMS:
Emboss cards locally
Dispatch ready cards to clients
Upload and check of cards data from Singapore host
The following external data should be used in this functionality:
On-line cards data
- Generated on demand and transferred through TCP protocol on a specified port
Client data
- Client-specific data (e.g. GRBID, phone numbers, address etc) should be retrieved from DWH_GRB database
Off-line cards data
- Generated periodically and stored in hand-off files of specified format in a secure folder
Stored procedure
-2 stored procedure from MobCom database should be used for SMS sending functionality:SMS data transfer to MobCom and SMS sending and delivery status by MobCom status
The following internal dictionaries should be entered by the user and used in functionality:
Image data
Layouts
CB Accounts
Accounts
Stocks
Hosts
Users
EXTRA! users
EXTRA! branch codes
Regions
Branch codes
Region codes
Product codes
Zip codes
Branches
Input Files
Streams
VIP indicators
Plastic types
Marketing paper
Marketing Packs
Card types
Scanning profiles
Upload profiles
Segregation profiles
Café Couriers
SMS templates
The following internal dictionaries are entered by system developers, not editable by users and used in functionality:
Layout types
Aliases
Hardware
Issue type
Chip types
Card classes
Origins
Record statuses
Cards statuses
Job statuses
Account types
Locations
Conditions
Customers
Batches Types
SMS creation modes
The following external libraries should be used in EMS:
larl.dll
IDAutomationDMATRIX6
Interleaved 2 of 5