Payment_Processing_L2_V0.1.ppt with detailed

Payments Processing
An Overview

| Financial Services
Contents
The information contained in this presentation is proprietary.
Copyright ©2011 Capgemini. All rights reserved.
1
1
Capgemini Payment Processing Overview
1. Payment Processing Stages
2. Payments Landscape

Contents
2
2
1. Payment Processing
1.a. Overview
1.b. Message Entry Points
1.c. Data needed for Payment processing
1.d. Stages of Payment Processing
1.e. Message Exit Points
1.f. Correspondent Banking
1.g. EOD and SOD Tasks

Overview of Payment Processing
3
 Payment processing includes everything that happens from the time the payment enters the
payments processor till the time it terminates in 'our books' (i.e. one of the accounts in our bank is
credited) or leaves 'our' processor (i.e. our banks payment processing engine) for outward clearing.
 In this section of training module we will come across
 Various entry point from where payments can originate
 Static data that is required by payment processor to be able to execute payments
 Stages of payment processing with details of important sub-functions they perform
 Various exit points for which payment may leave our system
 Banks also require to run some start of day (SOD) and end of day (EOD) tasks to enable some
important processes within banks, simplest of example being archiving and reporting. We will touch
base on some of these important tasks and uploads.

Message Entry Points
4
Payment Instruction Entry Points to Payment processing application
Payments can enter into payment processing engine through various channels – internal or
external to the bank. Below is the list of some of the important and most frequently used channels:
• In coming Clearing
̵ Swift
̵ Dedicated Incoming Interfaces from Clearing houses viz., ACH
• Corporate Access Channels
• Retail Channels
̵ Internet Banking
̵ Mobile Channels
̵ Branch Banking
• Bank internal Applications
̵ Trade Finance
̵ Cash Management
̵ Treasury
̵ Incoming Interfaces from partner banks

Data needed for Payment processing
5
 For the payment processing to work properly some static data needs to be setup in the payment
system.
 All payments refer to this data, as and when required, to determine next steps or additional steps to be
executed for taking it to proper completion.
 Few example of these are mentioned below:
Business Data – Availability of this information
help the business processes
• Users & entitlements
• Swift Directory; Bi-later key data
• Country and Currency Data
• Country Calendar
• Time Zones
• National Clearing Codes; Clearing Houses; cut-off
times
• Partner banks/Corresponding/Membership Banks
Info
• Customer & Account Data
• Direct debit authorizations
• Exchange Rates
• Fee Formulas
System Data – Availability of this information
helps the systemic processes
• Start of Day
• End of Day
• Data Extracts
• Batch Refresh
• Audit trail
• Maximum number of transaction info per screen
• Number of columns on the screen etc.,
• Technical Alerts

Stages of Payment Processing
6
There are mainly 5 Steps in which payment instruction is processed.
1. Payment Capture
 Payment is accepted in to the system and it is stored in different format at various sub stages
in Payment Capture stage.
2. Analysis
 Payment is analyzed by the system and which all steps are involved for payment processing is
done in this step / sub systems.
3. Decision
 All decision’s related to payments next steps are taken at this stage.
4. Delivery
 All processing related to delivery of message are performed by the system in this step.
5. Completion
 This is last stage where the payment system send final confirmation and final status to all
systems or feeder system and other process.

Payment Capture
7
P
A
Y
M
E
N
T
P
R
O
C
E
S
S
I
N
G
S
T
A
G
E
S
Capture
Analysis
Decision
Delivery
Completion
• Safe-store
Storing the incoming payment in the database
• Mapping and de-bulking
Mapping the payment fields and de-bulking of file if bulk file
is being processed
• Unique reference number generation
Assigning a unique number to the payment for the ease of
internal tracking
• Payment Validation
Validating the payment based on its source (e.g. Validating
account number format) and other such valid parameters
• Duplicate checking
Check to see if the payment received is not a duplicate of
any payment received earlier
• Repair and enrichment
Repair or enrich the payment so that it is processed as a
straight through rather than requiring manual intervention
• Regulatory check
To check if the payment is in accordance with the various
internal (bank procedures) and external (government
policies) regulatory bodies

Payment Analysis
8
P
A
Y
M
E
N
T
P
R
O
C
E
S
S
I
N
G
S
T
A
G
E
S
Capture
Analysis
Decision
Delivery
Completion
• Value Date
The date on which the payment gets realized in the account
will be determined
• Debit Party Identification
Identifying the account which is to be debited for making the
payment
• Debit Authorization
Determining whether the party ordering the debit of an
account is actually authorized to do so or not
• Payment/Cover Identification
Identifying whether it is a serial payment or cover payment
based on which debit account might change
• Account Restriction and Preferences
Customer might have some preferences set with the bank
e.g. do not debit certain account. These are evaluated in this
stage
• Account Reconstruction
IBAN/Account number reconstruction, if required

Payment Analysis cont…
9
P
A
Y
M
E
N
T
P
R
O
C
E
S
S
I
N
G
S
T
A
G
E
S
Capture
Analysis
Decision
Delivery
Completion
• Credit Chain Identification
Determining the first in credit chain
• Method of Payment (MOP) selection and validation
Identifying the various MOP that can be applicable to the
payments and running some validation on it to see if
payment suits the selected MOP
• FX Rate Conversion
If the payment involves FX then determining the rate
applicable and amount conversion using it
• Credit account identification
Based on MOP selected identifying the credit account which
maybe an individual account or a settlement account
• Special Instruction
Customer might have some special instructions with the
bank e.g. all dollar debit make from a certain account. These
are evaluated in this stage
• Cut off
Evaluating the cut offs of various method of payments and
bank internal cut offs as well

Payment Decision
10
P
A
Y
M
E
N
T
P
R
O
C
E
S
S
I
N
G
S
T
A
G
E
S
Capture
Analysis
Decision
Delivery
Completion
• Warehousing
Warehousing future dated transactions to be released later
as and when they approach their value date
• Advice generation
Sending the request for generating advices as and when
request by the customer
• Fee charging
Determining the fees amount to be charges and how to
charge it i.e. from payment or from account
• Balance Inquiry
Inquiring internally as well as externally (accounting system)
whether the required balances are available in the account
• Compliance Check
Running the payment through various sanctions and AML
checks – maybe internal as well as external
• Accounting
Generating the accounting entries for various accounts
involved (soft post)

Payment Delivery
11
P
A
Y
M
E
N
T
P
R
O
C
E
S
S
I
N
G
S
T
A
G
E
S
Capture
Analysis
Decision
Delivery
Completion
• Channel Identification
Identifying the delivery channel based on MOP selected
• Mapping
Format the messages as per delivery channel needs
• Bulking
If the need be, then bulk the message in files before sending
to channel identified
• Transmission
Actual sending of the message/s using the protocol
associated with the identified delivery channel
• ACK and Confirmation processing
Processing the ACKs/NACKs sent by the transmission
channel or message receivable system

Payment Completion
12
P
A
Y
M
E
N
T
P
R
O
C
E
S
S
I
N
G
S
T
A
G
E
S
Capture
Analysis
Decision
Delivery
Completion
• Advice Handling
Sending the request for generating advices as and when
request by the customer
• In-house Routing
Sending the request for posting, report generation and to any
other department as required by business to complete the
payment
• Archive
Moving the payment to inactive database
• Complete
Marking the payment as complete in the payment database
and updating statuses wherever required

Message Exit Points
13
Transaction Exit Points
As we have seen payment can leave the payment engine for various channels based on the
decision made. Some of the basic but important of these exit points are:
• Outward Clearing
̵ Swift
̵ Dedicated Outward Interfaces to Clearing houses viz., ACH
̵ CHIPS (Tape) functionality
̵ Correspondent/ Partner Bank
• Interfaces to applications on the landscape
̵ Compliance
̵ Customer
̵ Balance
̵ FX
̵ Accounting
̵ Warehousing
Note: All outward clearing mechanism will be explained in other L2 material. Only corresponding banking will be elaborated in this
presentation.
Ensures Transaction
Completion

Correspondent Banking
14
• Correspondent accounts are commonly used by banks internationally to undertake financial
transactions for themselves and their customers in jurisdictions where they generally have no physical
presence.
• The correspondent banking relationship definition relates only to banking services involving nostro or
vostro accounts.
 A nostro (Latin for 'ours') account is an account a financial institution holds with a foreign
financial institution, usually in the currency of the foreign country
 A vostro (Latin for 'yours') account is the account a financial institution holds on behalf of a
foreign financial institution.
• Correspondent banking relationships are vulnerable to money laundering and terrorism financing
because they involve a bank carrying out financial transactions on behalf of another bank's customers.
This indirect relationship means that the correspondent bank provides services in a situation where it is
unlikely to have either verified the identities or obtained first-hand knowledge of the respondent's
customers.
• Banks need to undertake an appropriate level of initial and ongoing due diligence on such accounts,
else they expose themselves to a range of risks associated with money laundering or terrorism
financing and may find themselves transacting funds that originated from illegal activity.

Correspondent Banking – an example
15
• Below is the example of the settlement of a correspondent bank payment between bank A and bank B
on behalf of two customers. Since banks A and B do not hold accounts with each other, they use bank
C (the correspondent bank), which holds mutual accounts with both bank A and bank B, instead.

EOD and SOD Tasks
16
• A task is a batch-type activity that can be run periodically
• Tasks are pre-defined in the system and are site-dependent (varies from installation to installation).
• The similar tasks are grouped into categories like Housekeeping etc.
• A special group of tasks is run daily, either at end or start of day. These are grouped in the Start-of-Day
and/or End-of-Day scripts.
• Some banks run all start/end of day tasks at EOD, and others split them between EOD and SOD.
• Below is the list of individual tasks that may be components of the EOD and/or SOD scripts
• Activate matured profile changes - This task activates the approved static data profile changes
when selected business date reaches the profile's effective date. Effective date represents the
date from which the changes in the profile is reflected.
• Clean deleted entries - All the entries that are marked as deleted during the day are actually
deleted through this task.

EOD and SOD Tasks
17
• Clean profile audit entries - Deletes audit log maintained for various static data profiles
changes with a date older than parameter specified in the system.
• Next business date - This task is used to advance the business day of the local system and
even various payment methods like clearing houses if required.
• Release from Scheduled - This function releases messages where the message processing
date is the same as or less than the local office business date from the Scheduled and Wait
Release queues (warehouse).
• Suspend Inactive Users - This task suspends all the users that have not logged in to system for
a defined period of time. The time period is calculated based on the last login date of the user.
• Move to History - This task sets payments to a history status. This task is only applicable to
payments with a final status such as Complete, Cancel or Rejected, and payments that are
matured, i.e. the current business date is greater than the processing date plus the date defined
by the system option.
• Delete From History - This task permanently deletes matured payments from the system.
Mature payments are those payments where the current business date is greater than the date
defined by the system option.

EOD and SOD Tasks - Uploads
18
• Various uploads are also done as part of EOD/SOD tasks. Some of them are explained below:
• BICPlusIBAN directory upload - This upload uses BICPlusIBAN directory as the input to
update Countries Info, Currencies Info, Customer and membership tables. IBAN structure
information is also updated during the process.
• SEPA Directory Upload - The task uploads SEPA records for Financial Institutions in the
system. It adds new members, maintains existing if required and deletes the records not
found in the new upload.
• Target2 Upload - The task uploads TARGET2 records for Financial Institutions in the
system. It adds new members, maintains existing if required and deletes the records not
found in the new upload.
• SWIFT RMA Upload - The process uploads SWIFT RMA records for Financial Institutions
into the system. The RELATIONSHIP MANAGEMENT APPLICATION (RMA) establishes a
relationship between 2 parties and controls who can send the messages, when can they
send and which message type they can send.
• Exchange Rate Upload - This uploads the exchange rates for various currency pairs to be
used by the system for payment conversion purpose. The frequency of this task varies from
Bank to Bank.

Bird Eye View of Processing
19
STP
System
Set-up
Preliminary
Processing
Core
Processing
Messaging
and
Accounting
Processing of
Global Payment
Messages
Risk
Management
Payments
Message
Processing
 Debit and Credit account
derivation
 Credit chain determination
 Payment Routing determination
 (Book, Clearing, Correspondent)
 Special instructions Handling
 FX Rates Conversion
 Fees Application
 Bulking of
Messages
 Dispatch
 Ack/Nack
 Receipt and
Matching
 Accounting Entries
& Advising
 SWIFT
 FED and CHIPS
 CHAPS
 SEPA and FPS
 Credit Risk
 Settlement Risk
 Liquidity Risk
 Credit Operational Risk
 Compliance / Regulatory
 Message Parser /
Formatter
 Message
Enrichment
 Self-Learning
 System and Business Data
 Set-up using batch loads interfaces /
data load scripts / manually
 Business Rules Definition &
Conditions
 Configurable business processing
 User driven parameters
 Safe store
 De-bulk
 Store split/individual messages
 OFAC/ Compliance check
 Message Enrichment
 Assign unique identifier/reference
 Acknowledgement to source systems

Contents
20

Contents
21
2.a. Introduction to Payment Landscape
2.b. Core Processor
2.c. Shared system
2.d. Up-stream system
2.e. Down-stream system
2.f. Side-stream system
2.g. Service examples
2.h. Capgemini Reference Model

Introduction to Payment Landscape
22
Middleware
Payment
Application
Downstream Systems
Side
Stream
systems
/
Clearing
System
Upstream Systems
Satellite
Feeder
Systems
Incoming
Clearing
Payments
Corporate
Channels
Back office
Systems
Shared
Services
Sanctions
AML
Reporting
Customer
Notifications
Billing
E&I
Balance App
Reconciliati
on
BIW Archival
Clearing
Gateways
Internal
Messaging
Switches
Business
Application
monitoring
Technical
Application
monitoring
Settlement
Application
Accounting
application

Introduction to Payment Landscape
23
 A payments landscape, sometimes referred to as an enterprise payments architecture, is an IT system
that allows banks to build their own version of a best-in-class payments architecture.
 Payment Landscape comprises of
• Feeder Systems /Upstream Systems/Front-end landing zone
• Core Processor/Product
• Business Support Systems/Side Stream Systems
• Shared systems (systems used by various departments of the bank)
• Gateways/Bank Payment Entry and Exit Systems
 Most banks and networks rely on transaction processing systems that are dedicated to specific types of
payments – wire transfers, credit cards, checks, electronic funds transfers and so on.
 These legacy systems are based on aging technology that is inflexible, increasingly expensive to
maintain and difficult to integrate with proliferating banking applications.

Core Processor
24
Core Processor involves following important steps:
 Message/File Receipt and Data Capturing
 Message data analysis
 Decision application
 Implement the decision and deliver
 Mark the payment message complete

Message/File Receipt and Data Capturing
25
 Safe store
 De-bulk
 Store split/individual messages
 OFAC/ Compliance check
 Message Validations Including Duplicate
Check
 Message Enrichment
 Assign unique identifier/reference
 Acknowledgement to source systems
 Message Parser /
Formatter
 Self-Learning
 System and Business Data
 Set-up using batch loads interfaces /
data load scripts / manually
 Business Rules Definition &
Conditions
 Configurable business processing
 User driven parameters
Application business
Setup / Readiness
Iterative
Indicative
Actions

Message Data Analysis
26
• Value Date
• Debit and Credit account derivation
• Account Reconstruction (IBAN)
• Debit and Credit Account Analysis
• Account Restrictions
• Account Preferences
• Credit chain determination
• Payment Routing determination
• (Book, Clearing, Correspondent)
• Validate the Direct/Cover, Serial Method
• Special instructions Handling
• FX Rates Conversion
• Fees Models/Application
• Cut-off of Clearing, FX, EoD etc.,
Indicative
Actions
Static Data, Business Rules, Business Flow Definition and Interfaces

Decision Application
27
• Warehousing of Value Dated transactions
• Calculate the Fee or create accruals for later-billing
• Arrive at the advice generation Info
• Use the Debit and Credit Account Analysis to arrive the account
balance information and also the limits
• Liquidity checks
• Settlement Risk
• Payment release
• Compliance Check-ups
• Create the accounting entries (including GLs) and hand it to
Accounting Application
Indicative
Actions

Implement the decisions and Deliver
28
• Identify the delivery channels
• Format the messages as per the delivery channel needs
• Deliver the message to Clearing System
• Receive NAK/acknowledgements
• Process the NAK/ACK
Indicative
Actions
Complete the transaction
• Push the entire data to archive

Shared System
29
Shared Systems are applications which can be accessed from multiple points in the payment
landscape or from discrete set of peripheral applications.
 Established means of improving operational efficiency and reducing costs.
 Not all services lend themselves to sharing
 Shared services can be home-grown bespoke or off-the-shelf products
 Improved utilization of resources (H/W, S/W, and people) leading to reduced requirements at the
aggregate level.
 Specialization in specific service areas by consolidating expertise into a single application
service, thereby enabling increased innovation and continuous improvement.

Upstream System
30
Upstream Systems are the entry point to the Payment engine. They are responsible for feeding
information to the payment engine
 Various customer-facing channels e.g. Internet banking, ATM, Kiosks etc. or internal (bank)
users initiating payments on the customer’s behalf or for departmental payments e.g. teller, core
banking etc.
 Back-office applications from other product areas such as loans, treasury, trade etc. for effecting
settlement of their transactions
 All the applications of the bank that originate the payments flow are categorized under Upstream
Systems category.
 This single integration point replaces the multiple interfaces required by the conventional
approach.

Downstream System
31
Downstream systems are responsible for receiving the information from the payment engine.
 It maintains the history of the transaction, storage, reconcile the transaction with other huge
number of applications and these applications also access the payment engine to support
various processes, either online or batch files or during the End of Day process.
 Functions include Reconciliations, undertake MIS/Reporting, Information ware-house, Data
archival etc.
 All such systems interfaces done on a post facto basis are categorized as Downstream Systems.

Side-stream System
32
Side stream systems furnish additional information during the course of payment processing. The
interface to these systems are invoked on need basis.
 Such applications include Funds checking & credit decision, advising, notifications, FX,
sanctions checking, SWIFT gateway, etc., to cite a few examples
 This information is generally dynamic in nature and hence necessitates a real-time interface in
course of processing the payment.
 It is also possible that such systems refresh the data set in the payments hub at the periodic
intervals (intra-day batch) for example FX base / card rates refreshed periodically through the
day.

Example: Upstream System - Channels
33
Objectives
 Channels had a profound impact on the way bank develop their products. Channels have an
impressive ability to transform complex requirements into innovative, user friendly solutions.
Standard Functions
 Channels enable a bank to easily create, manage and deliver segmented branding and product
offerings.
 Channels empower significant return on channel investment by ensuring maximum coverage
of the target payment product.
 Various channels are online banking, ATM, Branch, IVR etc.
 Lower cost of operating self-service channels than employee service channels offers the
opportunity of significant cost savings.

Example: Upstream System - Customer Information System
34
Objectives
 Provides essential information and various preferences of customers at account level or
customer level – so that payment application analyze the information and implement decisions
Standard Requirements
 In addition to the standard functionality included in a full-function, need has arisen for customer
self-service, online bill presentation and payment capabilities, automated workflow tools, and
complex rating and billing capability.
 Solution must be a product (rather than a custom solution), must be implemented with no or
minimal modification, must be flexible, and must use current, open technology.
 Analytical CRM with the objective of turning data into knowledge for strategic value.

Example: Shared Services-Payments Decision (Balance Check)
35
Objectives
 Payments Decision being the important function of payments, the application must be able to
provide the customer balance, as requested by Payments application, on real-time
Standard Functions
 Must be able to provide the balance at various levels viz., Clear balance in account, group
balance, shadow balance etc.,
 Must be able to provide the balance either at Customer level or account level
 Must be able to gather balance from various Bank internal applications and aggregate the
customer balance
 Must have the ability to auto refresh balances when it receives balances from other applications
 Must have the function to ‘Reserve the balance’ against a transaction
 Must have the ability to re-check the balance at frequent intervals, till a clear balance
information is available
 Must be able to provide balance-cut off notification to Payment applications
 Reject all the outstanding transactions at the cut-off time

Example: Shared Services - Sanctions
36
Objectives
 The application must be able to filter out messages where there is suspicion that the payment is
originated or destined for debarred people/countries
Standard Functions
 Hold the database of all the required sanctions lists
 Database must be able to get the updates and modify the data-base on real time
 Ability to check the payment messages on real-time (Individual and/or batch files)
 The application must have the ability to check all contents of the message (Ordering customer,
sender, Receiver banks, Beneficiary customer etc.,)
 Must have the ability to route the payments to exception queues, where system identifies the
message as black-listed
 The application must have the capability to provide summary reports at defined time intervals (
or may be configurable)
 Based on updates by operator, on the blacklisted message, system must be able to improve its
auto intelligence.

Example: Shared Services - Exceptions & Investigations
37
Objectives
 To Manage the customers queries on the payment message processing and enable the
operations teams to manage the queries
Standard Functions
 Provide the user with the ability to search for both in-flight and historical payments using a
unique payment ID or may be combination of multiple field information (Example: amount
range, date range, sending bank, receiving bank, Message type etc.,)
 System must be able to assign unique reference to the query or case and manage a case
through out the life stage of process
 Query messages can be assigned to investigators as required and reassigned if required.
 Resultant transactions of a search must be able to be drilled down for various checks (Example
entire Transaction processing, transaction audit etc.,)
 An investigator should be able to attach a note to query.
 System must be able to receive and generate MTx95, MTx96 and MTx99
 The investigation tool should automatically flag and prioritise a query with certain criteria e.g.
amount, customer.

Example: Shared Services - Reporting Service
38
Objectives
 The service should have the ability to generate reports in relation to payments activities in the
payments landscape
Standard Functions
 Ability to generate reports which can be viewed online and or printed as required.
 Ability to email reports to a defined list of recipients.
 Generate reports on payment operator activity such as changes to users’ access rights, number
of payments processed per operator
 The types of business information/reports that would be required
 Payment Values – per payment type, status, per payment queue, per destination, per
source, per currency, per payments scheme, per value date. per processing date, per
payment amount, per cut-off times, per account, per account type, per customer, payment
values in base currency of jurisdiction even if travelling currency differs etc
 Payment Volumes - per payment type, status, per payment queue, per destination, per
source, per currency, per payments scheme, per value date. per processing date, per
payment amount, per cut-off times, per account, per account type, per customer etc
 Operator Activity: number of payments processed, average processing time, per manual
payment queue

Example: Shared Services - Advice and Notification Service
39
Objectives
 The service should have the ability to generate the appropriate customer / internal advices and
notifications in relation to payments processed by Bank
Standard Functions
 All kind of reports
 Credit Advices
 Debit Advices
 Mini-Statements
 Acknowledgements
 Volume based reports at frequent time intervals
 Mode of advice / notification
 email, Text, Swift, dedicated internal channels
 There must be some flexibility for the customer to generate their own advices, where customer
is given web access

Example: Shared Services - Liquidity Management
40
Objectives
 Liquidity Management Service consolidates payment and transaction information, in real-time,
across multiple payment systems to provide a comprehensive enterprise-wide capability for
managing operational liquidity.
Standard Functions
 Provide accurate information to cash managers and funding managers to improve the utilization
of excess liquidity and cover liquidity shortfalls.
 Reduce operational costs :Eliminate the labor-intensive manual integration and manipulation of
multiple data sources and reducing errors
 Various liquidity management services provided in FI are cash concentration, notional pooling,
netting, simulation, forecasting etc.
 Core services: These encompass a range of established physical and notional liquidity
management techniques with traditional features and their associated in-depth reporting.
 Value Added features: These cover a number of ancillary functionalities that enrich the core
services proposition and enhance the user experience.
 Service extensions: These include tools that automate or improve complete liquidity
management disciplines, such as cash flow forecasting and investment management.

Example: Shared Services - Billing Service
41
Objectives
 In the context of payment charges, Billing applications will need to have the ability to debit the
customers account for charges owing to Bank, as a result of a payment initiated and processed
on behalf of the customer (internal or external).
Standard Functions
 Ability to calculate and apply payment charges to customer accounts and internal cost centres
(SAP system related structures).
 Apply charges at a defined later date, at various frequencies, e.g. daily, weekly, monthly, etc.
 Ability to calculate and apply charges in multiple currencies.
 Apply charges as individual debits to a customer/nominated account.
 Ability to bulk multiple charges and apply as one debit.
 Ability to calculate and apply charges based on static data setup such as Fee Formulae and
tiered pricing slabs on a per customer , per payments product etc.

Example: Side Stream System - FX Rates
42
Objectives
 Within the context of Payments processing, the FX application must be able to provide all
Foreign Currency Exchange rates to Payment processing application.
Standard Functions
 Provide rates, multiple times in a day where International currency rates are volatile
 The rate card must be able to provide required staggered rates
 The rate card must have the rates for those currencies defined in the payment application
 Rate cards prime currency is always defined to a particular currency

Example : Side Stream System-Business Activity Monitoring
43
Objectives
 Allow the business to monitor and manage payment events across systems and to provide
early warning mechanisms where there may be issues/bottlenecks about to occur in the
payment workflow (STP and manual processing).
Standard Functions
 Monitor the various statuses of the payment process within the Payments Application. Example
STP, Outstanding, Cancelled, Exception, Manual Authorisation required etc.,
 Drill down on the list of transactions that make up this queue/status
 A user should have the ability to attach/copy/paste a note to an event.
 Prioritise & order the list of events those should appear on screen
 Ability to produce MIS for reporting on the activities listed above
 Ability to send automated alerts regarding queue management / traffic light monitoring .
 The BAM software should automatically refresh/update at defined interval of time (seconds)
 Send alerts to Business community (management) viz., email, Texts etc.

Example: Side Stream System - Technical Monitoring
44
Objectives
 Technical monitoring concerns itself with the technical progress of payment and individual
services of processing. It focuses on the function of the payment object under review, rather
than the role that such an object plays in the payment system that it is part of.
Standard Functions
 Technical monitoring is the largest category of the payments services and is critical for the
payment processing and ensure completion.
 Other monitoring tools like functional monitoring and business process monitoring also take
help of technical monitoring.
 Technical monitoring aids in finding out what is wrong and how to fix?
 Various Important payment process which covered under technical monitoring are:
•The system must be able to generate accurate and complete copies of transaction data.
•Transaction data records must be protected.
•Payment system access must be restricted.
•Audit trails must be applied to all data.
•Operating system protection methods should be used where possible.
• Payment authorization checks must be applied.

Example: Downstream System- Archival & Retrieval
45
Objectives
 Archival process consolidates all the messages that have reached there finality and ports them
to a separate storage space to ensure that the payment processing engine has to skim through
live messages only.
 The messages that are archived can be retrieved as and when required for exception/
investigation or reports as required by the bank
Standard Functions
 Periodic check to identify the messages which qualify for archival.
 Maintain history of all the messages that have entered the system.
 Ability to produce information or reports on archived messages .
 Ensure that the archived message information is intact for a certain period of time.
 Retrieve the archived information based on certain parameter as and when required by bank for
an exception/investigation or internal reports.
 Retrieval are generally request based and are not done as part of normal processing.

Capgemini – Payment Reference Model
46
Offering and Usage
 Proven payment experience of Capgemini associates has been converted into Payment
Reference Architecture – A service based model
 It has comprehensive suite of Service flow based on peripheral and core services of Payment
Landscape
 Integrated view of end to end payment message processing
 Multiple opportunities to use in development & testing phase. Also assists in Scope definition
 Useful in Requirement Management
 Service design facilitates Functional Requirement identification
 Instrumental in System/ Process analysis
Benefits
 Facilitates optimization
 Helps in requirement identification
 Solution definition
 Useful in gap analysis
 Execution
 Helps come up with a cost effective model
 Reduced efforts
 Shorten time span for implementation

Capgemini – Payment Reference Model
47

True/ False
Question 1: Duplicate Checking is a part of Payment Analysis stage
True
False
Question 2: Repair and Enrichment is a part of Payment Capture stage
True
False
Question 3: In-house routing is done during Payment Completion
True
False
Question 4: Special Instructions are executed during Payment Decision
True
False
Quiz
© 2012 Capgemini - Internal use only. All rights reserved
48

True/ False
Question 5: Shared Systems are applications which can be accessed from multiple points
in the payment landscape or from discrete set of peripheral applications.
True
False
Question 6: AML and Sanctions are shared services
True
False
Question 7: Billing is a side stream system
True
False
Question 8: Technical Monitoring allows the business to monitor and manage payment
events across systems and to provide early warning mechanisms where there may be
issues/bottlenecks about to occur in the payment workflow
True
False
Quiz
49

MCQ
Question 9: Which of them is/are not a message entry point for payment system?
A. Internet transaction
B. Mobile Banking
C. Credit Card transaction
D. Branch Banking
Question 10: Which of the following is/are done during Payment Analysis?
A. Account Restriction and Preferences
B. Account Reconstruction
C. Balance Enquiry
D. Payment Validation
Quiz
50

MCQ
Question 11: Which is/are valid EOD/SOD uploads?
A. SEPA Directory Upload
B. SWIFT RMA Upload
C. BICPlusIPAN directory upload
D. Exchange Rate Upload
Question 12: Which of the following is/are not a EOD/SOD task?
A. Release from Scheduled
B. Complete Incomplete payments
C. Move to History
D. Delete From History
Quiz
51

MCQ
Question 13: Which of the following is not part of Business Data?
A. Country and Currency Data
B. Direct debit authorizations
C. Fee Formulas
D. Audit trail
Question 14: Which of the following is not part of System Data?
A. Alerts to be sent to customers
B. Maximum number of transaction info per screen
C. Data Extracts
D. Number of columns on the screen
Quiz
52

Fill In the blank
Question 15: __________ systems furnish additional information during the course of
payment processing and are invoked on need basis.
A. Up-stream
B. Shared
C. Side stream
D. Down-stream
Question 16: ____________ account is an account a financial institution holds with a
foreign financial institution, usually in the currency of the foreign country.
A. Nostro
B. Vostro
C. Correspondent
D. Settlement
Quiz
53

Fill In the blank
Question 17: The system must be able to generate accurate and complete copies of
transaction data – this check is part of _______________.
A. Business Application Monitoring
B. Technical Application Monitoring
C. Archival system
D. Reporting application
Question 18: ______________ helps monitor and manage payment events across systems
and provides early warning mechanisms where there may be issues/bottlenecks about
to occur in the payment workflow .
A. Business Application Monitoring
B. Technical Application Monitoring
C. Alert Management
D. Reporting application
Quiz
54

Fill In the blank
Question 19: ______________ provides essential information and various preferences of
customers at account level or customer level so that payment application analyze the
information and implement decisions
A. Account Information system
B. Customer Information system
C. Accounting system
D. Preference Storage System
Question 20: ________________ service is used to manage the customers queries on the
payment message processing and enable the operations teams to manage the queries
A. Reporting
B. Payment Search
C. Exception and Investigation
D. Customer Information system
Quiz
55

Payment_Processing_L2_V0.1.ppt with detailed

More Related Content

What's hot

Similar to Payment_Processing_L2_V0.1.ppt with detailed

Recently uploaded

Payment_Processing_L2_V0.1.ppt with detailed

Editor's Notes