Software for Payment Cards: Choosing Wisely

Software for Payment Cards: Choosing WiselyAs consumers increase their use of non-cash payments via debit/ credit/prepaid cards, financial institutions must improve their response times, strengthen their security, hone their future-readiness and enrich their business value. Selecting the best-fit packaged solution is a crucial element in meeting these objectives.
Executive SummaryAs the use of card-based payments soars, CIOs face the growing challenge of providing a robust and secure platform for processing the rising tide of transactions. The issue is compounded by the fact that more channels are being made available to consumers, along with more regula- tory attention to privacy — thereby intensifying the complexity of the software ecosystem. In this dynamic environment, the process of transition- ing to a new cards-processing platform brings with it ever-changing and increasingly demand- ing requirements. This white paper identifies the key elements involved in evaluating and selecting a cards software package that delivers on both short- and long-term business objectives. We will also explore three key factors that financial services companies should consider when navigating this process: • The rise of card-based payments. • The cards-processing ecosystem. • Best-fit package considerations.
The primary points discussed here will provide financial services institutions with the insights they need to navigate the RFP selection process and the implementation of a commercial off- the-shelf (COTS) cards package within a given IT landscape. The Rise of Card-Based PaymentsPayments are an indispensable part of consumer and business interactions, whether business-to- consumer (B2C) or business-to-business (B2B) transactions. Among the various kinds of payment methods, those involving cards have been steadily rising over the last decade. Changes in technology, consumer behavior, regu- latory requirements and the rise of millennials — all have influenced the acceptance of payment cards. The tri-annual report published by the U.S. Federal Reserve in 2013 underscores this point (see Figure 1 on the next page). • Cognizant 20-20 Insights
cognizant 20-20 insights | november 2014

cognizant 20-20 insights 2
Over time, non-cash modes of payment have
grown — causing a significant jump in card-based
payments (see Figure 2).
The Cards-Processing Ecosystem
To fully understand the complexities involved in
selecting cards software, it is useful to under-stand the cards ecosystem and typical payment
flow. For example, approximately 74.14 billion
transactions were conducted in 20101, the most
recent date this data was made available. The
usual network response time for such transac-tions
is 130 milliseconds.
Depending on the nature and region of a transac-tion,
a payment might have to pass through many
points and networks, as depicted in Figure 3 on
the following page. Some transactions, such as
signature debit transactions (which occur on Visa,
MasterCard and Discover networks) and credit
transactions follow essentially the same process-ing
route.
Figure 4 on page 4 shows the flow of the
real-time processing steps involved in a transac-tion
— from acquiring the transaction, through
its approval and back. The clearing and settle-ment process falls outside this function and is not
described here.
The Increase in Card Transactions
50
40
30
20
2003 2006 2009 2012
10
0
Prepaid card
Checks (paid)
ACH
Credit card
Debit card
Debit, credit and prepaid card trends include general-
purpose and private label payments. “Trends in Non-
Cash Payments by Number and Type of Transactions.”
Source: U.S. Federal Reserve System 2013 Report.
Figure 1
Billions
Growth in Non-Cash Payments
0
10
20
30
40
50
Checks ACH
2003
Credit Card Debit Card Prepaid Card
2012
Source: Information from “Exhibit 3 Distribution of Non-Cash Payments in 2012.” The U.S. Federal Reserve System
2013 Report. (The 2013 Federal Reserve Payments Study).
Figure 2

The Cards-Processing Ecosystem
Entity Description
Merchant POS
(point-of-sale devices)
The location where a transaction is initiated, acquired and approved by the card-
issuing bank. Once the transaction is approved, the merchant uses an end-of-day
batch process to provide the transaction information for the day to the clearing and
settlement house.
ATMs Machines that allow a cardholder to initiate a transaction, such as withdrawing cash,
making inquiries about an account balance, etc. These transactions are routed to
the card-issuing bank.
Local Payment Processors This refers to the local payment provider, which usually has a monopoly in a specific
geography. These providers have direct links to major local banks and aid in transac-tion
routing.
International Payment
Processors
Companies such as Visa/MasterCard/Discover, etc., are considered to be internation-al
payment processors.
Banks These can be either an issuing or an acquiring bank.
Quick Take
Banks*
Local Payment
Processors*
ATMs
Merchants
International
Payments Processors*
The Anatomy of Card Payment Processing
*Institutions where payments processing packages can be used.
Figure 3

PIN (personal identification number) transac-tions
require an additional step if the merchant
and issuing banks belong to different networks.
In these cases, the transaction passes through
the acquiring processor, then on to a gateway
processor that acts on behalf of a national EFT
(electronic funds transfer) network, such as Visa’s
Interlink or MasterCard’s Maestro. These national
networks serve as a bridge between the regional
ones. With the gateway processor, the transac-tion
is then routed in the same way to the issuing
bank’s processor, then on to the issuing bank for
authorization. The response is relayed back via
the same route in reverse — all the way back to
the initiating device.
Considering a Best-fit Package
Given such a complex ecosystem and time con-straints, selecting the right packaged solution
for a cards-processing platform is of paramount
importance. Figure 5 on the following page lists
some key considerations.
Real-time Card-Transaction Processing
Step Description
1
The consumer selects a card for payment. The cardholder data is entered into the merchant’s payment
system, which could be the POS terminal/software or an e-commerce Web site.
2
The card data is sent to an acquirer/payment processor, whose job is to route the data through the pay-ments system for processing. With e-commerce transactions, a “gateway” provider may provide the link
from the merchant’s Web site to the acquirer.
3
The acquirer/processor sends the data to the payment brand (e.g., Visa, MasterCard, American Express,
etc.), which forwards it to the issuing bank/issuing bank processor.
4
The issuing bank/processor verifies that the card is legitimate, not reported lost or stolen, and that the
account has the appropriate amount of credit/funds available to pay for the transaction.
5
Once the card is verified, the issuer generates an authorization number and routes this number back to the
card brand. With the authorization, the issuing bank agrees to fund the purchase on the consumer’s behalf.
6 The card brand forwards the authorization code back to the acquirer/processor.
7 The acquirer/processor sends the authorization code back to the merchant.
8 The merchant concludes the sale with the customer.
Figure 4
1 2 3 4
8 7 6 5
Consumer Merchant Acquirer/Processor
(Merchant’s Bank)
Payment
Processor
Issuer
(Cardholder’s Bank)

Evaluation Criteria for Cards-Processing Software
Category Consideration Points Description
General
Compliance Should be compliant with security standards and
international/local card schemes.
Migration Should offer ease of migration from an existing
in-house or COTS solution.
Market Reputation Provider’s reputation for after-sale services, as well
as the experience of existing clientele.
Functional
Authorization Ability and flexibility needed to authorize transac-tions, either by communicating with authorizing
banks or acting as a stand-in.
Clearing and Settlement Ability to provide information for CSM processing,
as well as receive CSM batch files for final settle-ment with various other banks/processors.
Issuing Management Support for omni-channel and multi-channel fraud
detection/management.
Acquisition Management Support for acquisition channels with flexible
pricing models.
Non-Functional/
Technical
Architecture Ability to fit within the existing IT landscape, with
scalability options.
Network Support Should provide support for communication chan-nels
such as TCP-IP, HTTP, etc., and work with
industry-leading messaging middleware solutions.
Device Hosting Should support hosting of multiple devices and
related communication protocols.
Risk Management
Fraud Detection and Prevention Ability to detect fraud in real time, with provisions
for preventing future suspicious transactions.
Ease of Configuration Ability to perform online actions to modify limits,
block accounts, execute geography-specific block-ing
and provide various types of reporting. In short,
a parameterized product that gives the power to
the business users, rather than doing everything by
scripting/code modifications.
Ability to Execute
Implementation Capability Ability of the package owner to be a reliable system
integrator.
Time to Market Ability of the package to foresee market chang-es and remain compliant with the latest market
standards.
Cultural Fit Soft-skills aspect of the vendor/institution
relationship.
Figure 5
General Considerations
When selecting a cards software solution, the fol-lowing general points should be kept in mind:
Compliance
• Data security standards. Data security
standards are critically important, given that
institutions routinely deal with customers’
private and confidential data. Any compromises
to this data can have serious financial and
reputational impacts, affecting both firms and
their customers. Hence, a software solution
should be compliant with: > > A leading data security standard, such as PCI
DSS (Payment Cardholder Industry Data Se-curity Standard). > > Local/international standards imposed by
law in the area of operations.

• Card schemes. A cards processor needs to
interact with various interchanges or networks
to ensure that customers can receive expected
levels of service throughout the world. Hence, a
solution should support various card schemes,
such as MasterCard, VISA, RuPay, Maestro and
American Express.
Migration
Migration is extremely significant in a situation
where an institution has an in-house or COTS
product already in place and chooses to adopt a
new software package. In these cases, the follow-ing
considerations must come into play:
• Ease of migration to the new product.
• Support of package vendor in setting up
governance model for migration.
• Big-bang or phased approach with detailed
timelines.
• Impact on current business.
Market Reputation
A software package’s market reputation should
be studied before it is selected, since this infor-mation
can offer more insight regarding:
• The actual capability of the package in all
aspects of transaction processing.
• Practical difficulties and problems during use.
• Existing clienteles’ experience with the
package.
• Agreements regarding after-sale services.
Functionality
Every payments-processing institution will have
its own functional requirements, based on its
core business requirements. A software package
should be able to readily fulfill these needs, with
minimum customization. Among the core func-tional
aspects to be considered are:
Authorization
This is a core step in transaction-processing. The
factors that come into play include:
• Flexibility. Since authorization rules are very
dynamic and change according to business
rules and regulations, it is very important
that the software package be able to accom-modate these fluctuations — in less time, and
with minimum impact on the business and
its customers.
• Ability to authorize transactions using all
types of cards. The product should be capable
of supporting authorization of processed trans-actions
using different types of cards, such as
magnetic stripe cards, contactless cards and
EMV (EuroPay, MasterCard, Visa), for example.
• Ability to authorize transactions performed
at all types of terminals. Card-based transac-tions
can be performed on different types of
terminals — ATMs, POS, EMV-capable and con-tactless payment terminals. Thus, a solution
must be equipped to handle transactions origi-nating
from a wide variety of terminals.
The software should be able to act as a stand-in
for authorization in the event the destination
host is down. It should also be able to connect
to multiple hosts in situations such as mobile
recharge, which requires the solution to con-nect
to the bank for balance approval while
simultaneously connecting to the telecom ser-vice provider to conduct a balance top-up.
• Support multiple authorization types and
flows. > > Different types of transactions may need dif-ferent types of authorization, depending on
the business need (pre-screening, balance
approval, limits and usage checks). > > Special transactions may need to be sent to
different destinations (multiple hosts, fraud
management systems, etc.). Consequently,
the package should be capable of supporting
these systems, and split or limit different
types of authorizations across multiple
destinations.
Clearing and Settlement
The ability of an institution to clear and settle
transactions helps to control its exposure to
financial risks. A cards software package should
thus be capable of supporting the various func-tions
associated with this process — quickly, and
with minimum customization. Key considerations
include:
• Reporting of matched and unmatched transac-tions.
• Creating bookings for transactions to be
settled and sent to host if needed.
• Creating customized reports based on current
business needs.
• Configurable reversal of unsettled transactions.

• An interface for the institution’s staff to view
individual transactions and correct them if
needed.
• Configuration of clearing and settlement flows
based on types of transactions.
• Configurable fee schemes based on type of
transaction, issuer, acquirer, etc.
Issuing Management
An institution must provide its customers with
the services they expect. Likewise, customers
must manage the risk arising from those services.
A COTS software package should help an institu-tion
support these objectives. Key considerations
include:
• Support for multilingual, multicurrency and
multinational customers.
• Support for multiple card products, such as
mobile cards, contactless cards, etc.
• Configurable risk-management solutions such
as fraud scoring, at various levels — customer,
card or type of transaction.
• Ability to interact with an external card
management system if needed.
Acquiring Management
An institution’s ability to be lean and efficient
while providing support for multiple acquiring
channels helps increase its competitive advan-tage in the acquiring market. Hence, a card
software package should offer support for:
• Multiple acquiring channels like ATM, POS, NFC
terminals, etc.
• Multiple pricing schemes for customers.
• Loyalty programs.
• Configurable reporting formats for customers.
• Multiple issuer routing.
Non-Functional/Technical
Considerations
The non-functional aspects of a COTS package
are equally important when making a selection,
since the software must fit into an institution’s
existing IT applications landscape.
Architecture
The package should be compatible with the IT
architectural principles of the institution. There
should be minimum or no impact on the current
architecture. Key considerations include:
• Multi-platform support.
• High availability and performance.
• Scalability and dynamic load balancing.
• Manageability.
• Security.
• Easy integration with external systems.
Network Support
Communication is an important consideration.
A cards software solution should be able to
integrate and communicate with external sys-tems using a wide variety of network protocols.
Consequently, the package should support:
• Multiple communication protocols, such as
TCP-IP, HTTP and UDP.
• Multiple messaging middleware.
• Secure communication channels.
Device Hosting
The package should support multiple devices and
accommodate required communication proto-cols in order for them to function properly. These
capabilities encompass:
• ATM and CDS hosting.
• Support for key management and key loading
of hosted devices.
• Support for multiple types of transactions
from hosted devices.
Risk Management Considerations
For institutions handling payments, risk manage-ment is a primary weapon for combating fraud.
Given the continuous flow of news surround-ing
data theft and increases in card-not-present
fraud, managing risk becomes even more critical.
The following points should be top of mind:
Fraud Detection and Prevention
Detecting fraud is the first step in preventing it.
Hence, the software package should be able to:
• Support multiple fraud-detection algorithms.
• Integrate with real-time/near real-time fraud
detection systems.

Ease of Configuration
Fraudsters use a variety of techniques. They are
very dynamic. To combat fraud, the software
package should be flexible enough to enable the
following:
• Intuitive selection of fraud-detecting
algorithms.
• Easy configuration of any new algorithms.
• Simple configuration of general limits and
usages for preliminary checks.
• Geographical blocking and maintenance of
blocking rules.
Ability to Execute
The selected cards software package might have
all the capabilities an institution needs; however,
if the vendor does not have the skills and expe-rience needed to install and operationalize the
solution, the firm’s business can be seriously
affected. The following criteria can shed the nec-essary light on a vendor’s or systems integrator’s
capabilities.
Implementation Skills and Services
The vendor/system integrator should offer:
• Knowledgeable, experienced resources for
package deployment and implementation.
• Support and documentation for implementa-tion
and maintenance.
• Training for existing IT operations and business
process owners.
• Services to maintain customer-specific modifi-cations
if needed.
Faster Time to Market
Institutions gain an advantage over their com-petitors when they are ahead in deploying new
products and bringing new services to market.
Hence, an implementation partner or vendor
should be able to:
• Provide solutions for quickly resolving
production problems.
• Deliver any changes/improvements to the
software package ahead of schedule.
• Follow any mandates from interchanges as or
before needed.
• Provide easily configurable and implantable
solutions for business evolution.
• Be the first to address any modifications to
the BIM (bank interchange message) or other
standards that are widely adopted in local/
international markets.
The Right Fit
How a package vendor’s organization serves
and communicates with the client organization —
from helping to choose the software, to guiding
the client through the implementation process, to
regularly communicating with project sponsors —
is a fundamental component in any successful,
future-focused implementation.
Looking Ahead
As with any COTS product, an outdated solution
with its own in-house, custom-built applications
can significantly increase transaction-process-ing
expenditures, escalate maintenance costs,
slow time-to-market and result in lost business
opportunities.
No off-the-shelf cards software product is a “buy-
and-implement” proposition. However, equipped
with a well-designed, well-implemented solution
supported by a qualified vendor, institutions will
be better positioned to increase their agility and
flexibility, improve how they control risk, and pro-vide
their customers with a secure platform for
successfully managing their card transactions.
References
• The 2013 Federal Reserve Payments Study. http://www.frbservices.org/files/communications/pdf/
research/2013_payments_study_summary.pdf.
• First Data thought paper. https://www.firstdata.com/en_us/insights/payments-101-white-paper-/_jcr_
content/content-block/insight_individual/insights-downloads-par/download/file.res/fd-Payments-
101-Credit-and-Debit-Card-Payments-white-paper.pdf.
• 2010 BAI & Hitachi Study of Consumer Payment Preferences. https://www.bai.org/Libraries/LOB-
Research-Downloads/BAI_Hitachi_2010_Consumer_Payment_Preferences_Study_for_Purchase.sflb.
ashx?download=true.
• http://www.nilsonreport.com/.

About Cognizant
Cognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting, and business process out-sourcing services, dedicated to helping the world’s leading companies build stronger businesses. Headquartered in Teaneck, New Jersey (U.S.), Cognizant combines a passion for client satisfaction, technology innovation, deep industry and business process expertise, and a global, collaborative workforce that embodies the future of work. With over 75 development and delivery centers worldwide and approximately 199,700 employees as of September 30, 2014, Cognizant is a member of the NASDAQ-100, the S&P 500, the Forbes Global 2000, and the Fortune 500 and is ranked among the top performing and fastest growing companies in the world. Visit us online at www.cognizant.com or follow us on Twitter: Cognizant.
World Headquarters
500 Frank W. Burr Blvd.
Teaneck, NJ 07666 USA
Phone: +1 201 801 0233
Fax: +1 201 801 0243
Toll Free: +1 888 937 3277
Email: inquiry@cognizant.com
European Headquarters
1 Kingdom Street
Paddington Central
London W2 6BD
Phone: +44 (0) 20 7297 7600
Fax: +44 (0) 20 7121 0102
Email: infouk@cognizant.com
India Operations Headquarters
#5/535, Old Mahabalipuram Road
Okkiyam Pettai, Thoraipakkam
Chennai, 600 096 India
Phone: +91 (0) 44 4209 6000
Fax: +91 (0) 44 4209 6060
Email: inquiryindia@cognizant.com
© Copyright 2014, Cognizant. All rights reserved. No part of this document may be reproduced, stored in a retrieval system, transmitted in any form or by any
means, electronic, mechanical, photocopying, recording, or otherwise, without the express written permission from Cognizant. The information contained herein is
subject to change without notice. All other trademarks mentioned herein are the property of their respective owners.
Footnote
1 According to The Nilson Report, 74.14 billion transactions were conducted with payment cards in 2010. (See The Nilson Report, Issue 985, page 10. December, 2011).
About the Authors
Meenakshi Sundaram Arunachalam is a Senior Manager within Cognizant’s Banking and Financial
Services Business Unit. He has fourteen-plus years of experience as a solution architect and HP
Tandem Nonstop technical architect for domestic and cross-border payments projects. His areas
of expertise involve pre-sales, architecture consulting and large-scale project management. He
holds a master of computer applications from Madurai Kamaraj University from India. Meenakshi
can be reached at MeenakshiSundaram.A@cognizant.com | LinkedIn: https://www.linkedin.com/in/
meenakshisundaramarunachalam.
Rammurthy Mudaliar is a Manager within Cognizant’s Banking and Financial Services Business Unit.
He has nine-plus years of experience in designing and application-building for European banks using
Wallstreet Systems’ Atlas/GBS product suite. His areas of expertise lie in the FX, money-market, trea-sury
and cross-border payment domains. He holds a bachelor of engineering in electronics from Mumbai
University. Rammurthy can be reached at Rammurthy.Mudaliar@cognizant.com | LinkedIn: https://www.
linkedin.com/in/rammurthymudaliar.
Vinay Chander Daida is an Associate within Cognizant’s Banking and Financial Services Business Unit. He
has seven-plus years of payments application-building experience with Cobol for European banks across
the complete SDLC lifecycle. His areas of expertise lie in the retail banking and cards domain. He holds a
bachelor of chemical engineering from Vellore Institute of Technology in India. Vinay can be reached at
VinayChander.Daida@cognizant.com | LinkedIn: https://www.linkedin.com/in/vinaychanderdaida.

Software for Payment Cards: Choosing Wisely

More Related Content

What's hot (19)

Viewers also liked (11)

Similar to Software for Payment Cards: Choosing Wisely (20)

More from Cognizant (20)

Software for Payment Cards: Choosing Wisely