EMS - Embossing Management System

Stages of the process

Type of plastic cards

Functional solution

4.Cards embossing

5.Plastic stock managing

6.Cards dispatching

2.Data for cards processing in Singapore and resending to Citi Russia

7.Delivery tracking

1.Client application acceptance at the front end and sending data to Citi Singapore

Banking cards

Non-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.

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.)

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)

VIP

Main

Primary

Additional

VIP

Main

Primary

Additional

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

At bank branches on installed printers

Outside the bank at outsourcing company (referred to as Rosan)

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

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

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

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

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 CW, 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.

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.

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

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.

Secondary

Secondary

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

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

Courier delivery

Direct customer pick-up

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.

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.

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