WHITEPAPER & TXVIA | Prepaid Card Processing with a

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

For additional information, contact:

Colette A. Oliver
TxVia, Inc.
340 Madison Ave., 3rd Floor
New York, NY 10173
(212) 937-4115
[email protected]

© 2008 TxVia, Inc. All Rights Reserved. This document, and the information contained therein, is
proprietary to TxVia, Inc. and is protected by copyright and other intellectual property laws. The
furnishing of this document does not give you any license to any of these intellectual property rights.
,Q DGGLWLRQ WKLV GRFXPHQW FRQWDLQV FRQ¿GHQWLDO DQG SURSULHWDU\ LQIRUPDWLRQ EHORQJLQJ WR 7[9LD
Inc. This document, and the information contained therein, may not be reproduced, distributed,
transmitted, disseminated or otherwise disclosed to any third party without TxVia’s express written
consent, and you may not use the information contained herein for any purpose other than the
VSHFL¿F LQIRUPDWLRQDO SXUSRVH IRU ZKLFK LW ZDV SURYLGHG 7KLV GRFXPHQW ZKLFK UHSUHVHQWV WKH
current view of TxVia on the issues discussed, is for informational purposes only, and TxVia makes no
warranties of any kind, express or implied, with respect to the document or the information herein.
TxVia is a trademark/service mark of TxVia, Inc. The names of any actual companies and products
mentioned herein may be the trademarks/service marks of their respective owners.

www.txvia.com
 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

CONTENTS |

I. Introduction 2

A. Complexities of Prepaid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

B. Inability to Use Credit and Debit Platforms for Prepaid . . . . . . . . . . . . . . . . . . . . . . . . .2

C. Emergence of Specialty Prepaid Card Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

D. Current Delivery Models for Prepaid Processing:

Software as a Service (SaaS) and In-House Software . . . . . . . . . . . . . . . . . . . . . . . . . .4

II. Inability of Current Delivery Models to Manage Complexities of Prepaid 4

A. Software as a Service (SaaS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

B. In-House Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

III. TxVia’s Platform as a Service (PaaS) Delivery Model 6

,9 7HQ6SHFL¿F/LPLWDWLRQVRI6DD6DQG,Q+RXVH
6RIWZDUH%HQH¿WVRITxVia’s PaaS Delivery Model 9

1. Limitations on reliability and scalability of platforms . . . . . . . . . . . . . . . . . . . . . . . . . . .9

2. Lack of development transparency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Lack of operational transparency; inability to timely track service level breaches. . . . . . 11

 ,QHI¿FLHQWDOORFDWLRQRIUROHVDQGUHVSRQVLELOLWLHVDQGLQDELOLW\
for issuers and program managers to take control; lack of
VXVWDLQHGXWLOLW\RISURJUDPDQGSURGXFWFRQ¿JXUDWLRQVFUHHQV . . . . . . . . . . . . . . . . . . 12

5. Inability to appropriately manage costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6. Inability to timely introduce product enhancements;

inability to protect intellectual property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

7. Limitations on ability to readily integrate into key products and services providers . . . . 16

8. Limitations on ability to deploy platforms and programs internationally . . . . . . . . . . . . 17

9. Obsolescence and limitations on life of platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

10. Challenges with PCI-DSS compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

9 ([DPSOHRI(I¿FLHQF\DQG(IIHFWLYHQHVVRI7[9LD¶V
PaaS Delivery Model—Integration to Star® Network 20

© 2008 TxVia, Inc. All Rights Reserved.

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

I. Introduction
Prepaid cards are amongst the newest entrants in a 50-year continuum of network
branded card products that have transformed the way people pay. As with credit and
debit cards, prepaid cards utilize the Visa®, MasterCard®, Discover® and American
Express® networks as well as various EFT networks to automate payments.

The prepaid card industry emerged about a decade ago and is now in the early majority
stage of product adoption. Prepaid cards represent one of the fastest growing segments
of card-based payments and hold tremendous potential to continue to transform
SD\PHQWVIURPLQHI¿FLHQWODERULQWHQVLYHSDSHUEDVHGPHWKRGVWRHOHFWURQLFV\VWHPV
The success of prepaid cards is attributable to value propositions such as convenience,
cost savings and security for businesses, governments and consumers.

The prepaid card category has many strengths. It consists of a broad product
set—ranging from nonreloadable gift cards to health care cards to general purpose
reloadable cards. Prepaid cards have utility across a wide range of vertical
applications—from incentives to payroll to government disbursements. And, they
DUHFRPPHUFLDOL]HGE\DEURDGVSHFWUXPRIRUJDQL]DWLRQV²IURP¿QDQFLDOLQVWLWXWLRQV
WRQRQ¿QDQFLDOLQVWLWXWLRQVVXFKDVLQFHQWLYHFRPSDQLHVSD\UROOVHUYLFHSURYLGHUV
retailers and money transfer companies (referred to in this white paper collectively
as “issuers and program managers”).

A. Complexities of Prepaid
But the strengths of the prepaid card category also represent many of its inherent
challenges. Unlike credit and debit cards, which are largely homogeneous
SURGXFWVFRPPHUFLDOL]HGSULPDULO\E\DVLQJOHW\SHRIRUJDQL]DWLRQLH¿QDQFLDO
institutions), prepaid cards present tremendous complexities:

:: Breadth of card products

:: Variety of marketing strategies and distribution channels
:: 'LYHUVLW\ RI YDOXH FKDLQ SDUWLFLSDQWV ZKLFK LQFOXGH ¿QDQFLDO LQVWLWXWLRQV
(FIs) and non-FIs of various kinds including networks, processors, program
managers and distributors
:: Divergent business models, value propositions and risks for each stakeholder
by product, vertical and distribution method
:: Differing technology infrastructure and operational support requirements by
product, vertical and distribution method
:: Rapid ongoing change and evolution due to the early stage of the market

B. Inability to Use Credit and Debit Platforms for Prepaid

Electronic card processing systems have existed for many decades, initially
serving the charge and credit card market and later the debit card market. With
the emergence of prepaid cards in the late 1990s, it became apparent that these

© 2008 TxVia, Inc. All Rights Reserved. 2

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

legacy platforms do not lend themselves well to processing prepaid cards because
of the unique complexities of prepaid, as described above.

Retreading credit and debit card platforms to process prepaid cards has
consistently proven unsuccessful. While credit card processing platforms may be
feature and functionality rich for credit cards, their capabilities are fundamentally
and materially different from those required for prepaid in numerous material
respects, including:

:: $FFRXQWRQ¿OH PDQDJHPHQW V\VWHPV DQG WKH QHHG LQ SUHSDLG IRU
many-to-many relationships between cards, accounts and users (i.e., multiple
purse technology)
:: Authorization pipeline logic, such as the need to limit the usability of cards by
purse, payment type, merchant, time and other parameters, including on a
combined basis
:: Ease of integration into numerous third-party systems
:: )UDXGDQGULVNPDQDJHPHQWVXFKDVXVHUYHUL¿FDWLRQDQGYDOXHORDGPRQLWRULQJ
and controls
:: Seasonal platform volume management
:: 1RQ¿QDQFLDOWUDQVDFWLRQSURFHVVLQJ
:: Inventory management
:: Real time processing of data and transactions
Adapting traditional card processing platforms to prepaid is also challenging
because they tend to limit scale and performance concerns to clearing and
settlement. While undoubtedly important, such concerns are the tip of the iceberg
for a prepaid processing system. Other forms of activity—such as Web, IVR,
activation, bulk issuance, API calls and value loads—can dominate the processing
work of a prepaid platform. Credit card platforms are not typically designed to
GLUHFWO\SURFHVVVXFKDFWLYLW\LQDUHDOWLPHPDQQHUDWVLJQL¿FDQWYROXPH

While retreaded credit card platforms may give the appearance and perception
of viability for prepaid card processing, their utility diminishes beyond the most
basic prepaid card products offered through simple channels. The additional
architectural and functional “baggage” of credit card platforms further erodes the
ability to leverage their limited functionality that would otherwise be appropriate
for a prepaid portfolio.

C. Emergence of Specialty Prepaid Card Processors

Based on the inability to utilize credit and other legacy card processing platforms
for prepaid, in the late 1990s and early 2000s companies that specialized in prepaid
card processing systems began to emerge and dominate the landscape. These
companies use primarily a “software as a service” (SaaS) approach to processing.
The early prepaid card processors that were successful were acquired by large

© 2008 TxVia, Inc. All Rights Reserved. 3

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

established payments processors, and additional entrants have since emerged.

Today, these specialty prepaid card processors remain the primary option for
prepaid card processing systems.

D. Current Delivery Models for Prepaid Processing:

6RIWZDUHDVD6HUYLFH6DD6DQG,Q+RXVH6RIWZDUH
Despite the emergence of specialty prepaid card processors, today’s prepaid card
HQYLURQPHQW KDV D QXPEHU RI FULWLFDO OLPLWDWLRQV VWHPPLQJ IURP GH¿FLHQFLHV LQ
enabling processing technology that prevents the prepaid card portfolios and
businesses of issuers and program managers from attaining their full potential.

7KH¿UVWGHFDGHRISUHSDLGKDVVHHQRQO\WKHLQLWLDODWWHPSWDWJHWWLQJSURFHVVLQJ
WHFKQRORJ\ ULJKW IRU WKH LQGXVWU\ WKHUH UHPDLQ VLJQL¿FDQW DQG VXEVWDQWLYH
improvements to be made. The initial generation of technology born in the 1990s
KDV VLPSO\ IDLOHG DW SURYLGLQJ UHOLDELOLW\ VFDODELOLW\ ÀH[LELOLW\ WUDQVSDUHQF\ DQG
other critical capabilities that the industry needs to grow and evolve fully. As a
direct result of the fast paced growth in card volumes and functionality, there is
QRZDZHERIVRIWZDUHSODWIRUPVWKDWKDYHEHFRPHGLI¿FXOWWRHQKDQFHRUVFDOH
in a material way.

Limitations result from the fundamental ways in which enabling technology for
prepaid cards is currently delivered:

:: As software as a service (SaaS) platforms offered by third-party processors

to issuers and program managers on an outsourced basis
:: As in-house software platforms offered by software vendors and deployed
internally by issuers and program managers

II. Inability of Current Delivery Models to

Manage Complexities of Prepaid
As described above, prepaid cards represent a broad array of card types. During the
past decade, a diverse group of organizations has emerged that commercialize this
wide-ranging spectrum of prepaid cards across various verticals and industries. Even
within a product set, these entities may occupy different positions in the value chain.
Collectively they use an extensive assortment of sales, marketing and distribution
channels. The result is that prepaid products present tremendous complexities not
seen with other types of payment cards.

A. Software as a Service (SaaS)

The software as a service (SaaS) model for prepaid card processing has focused on
a single, shared platform approach; whereby third-party processors cater to all of
their clients and all of their respective card types and go-to-market strategies with
a single software ecosystem managed by the processor. While these platforms
PD\ OD\ FODLP WR ÀH[LELOLW\ ZKHQ FRPSDUHG WR WUDGLWLRQDO FUHGLW DQG GHELW FDUG

© 2008 TxVia, Inc. All Rights Reserved. 4

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

platforms, they have consistently proven unable to manage the complexities of

prepaid. The existing offerings have, therefore, failed to stay current in meeting
the technical and operational processing needs of the prepaid card industry as it
has matured.

For example, an issuer or program manager invariably requires only a fraction of

a third-party processor’s shared software platform’s capabilities for its particular
prepaid card program(s). The unnecessary excesses of the platform result in
material challenges for issuers and program managers, such as:

:: Increased program management costs

:: Platform reliability and scaling hurdles
:: Time-to-market delays for product enhancements
As a result of the dominance of SaaS-based shared processing systems, today’s
SUHSDLGFDUGLQGXVWU\LVGHSHQGDQWRQ³RQHVL]H¿WVDOO´RXWVRXUFHGSODWIRUPV
Third-party processing is considered by many to be a material weakness of
the industry. This weakness should concern almost all prepaid card issuers
and program managers. In the case of general purpose reloadable cards,
for example, this weakness prevents achieving the day-to-day processing
excellence needed to allow consumers to access critically important funds. At
the other end of the prepaid product spectrum, it stands in the way of ensuring
the scalability needed for large quantities of gift cards and usage peaks.

In some cases, third-party processors have created client-segregated platforms

to overcome the challenges inherent with shared environments. In the process,
they have simply added hurdles typical of divergent code bases, such as ensuring
new functionality is made available to each platform branch. This divergence of
code creates version management responsibilities in the software development,
FRQ¿JXUDWLRQPDQDJHPHQWDQGGDWDFHQWHURSHUDWLRQV7KHVHUHTXLUHPHQWVFDXVH
delays in the implementation of new enhancements. If not properly managed, some
of the product features are completely locked out from a segregated platform.
All of this results in higher costs for all the participants in any given program.
As technology resources continue to be constrained by budgets and bottom-line
focus, code divergence represents a strong barrier to the improvement of many
prepaid products.

% ,Q+RXVH6RIWZDUH
In-house software solutions are often marketed to prepaid card issuers and
program managers on the premise that (1) they provide greater control over
processing than can be attained with SaaS processing systems and (2) the long-
term pricing is lower than offered by third-party processors.

In prepaid, however, in-house software solutions only provide the illusion of control
and cost savings. Software solutions available for processing prepaid cards have

© 2008 TxVia, Inc. All Rights Reserved. 5

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

not generally been designed from the ground up to process prepaid but have been
PRGL¿HGIURPRWKHUVRIWZDUHRIIHULQJVVXFKDVFUHGLWFDUGSURFHVVLQJV\VWHPV
DQGUHWUR¿WWHGLQDQDWWHPSWWRRIIHULQKRXVHSUHSDLGSURFHVVLQJFDSDELOLWLHV$V
described above, due to the origins of these software systems outside of prepaid,
they contain many attributes not required or designed for prepaid. As a result,
they are challenging to successfully manage long-term for any breadth of prepaid
products sold through multiple channels.

The unused attributes, combined with the legacy nature of these systems,
manifests itself in hidden system integration expenses that typically spiral out of
control. In addition, they invariably have far greater internal build requirements
than originally planned. For example, with the variety of integrations typical of
SUHSDLG SURFHVVLQJ V\VWHPV PXFK WLPH FDQ EH VSHQW ¿WWLQJ VTXDUH SHJV LQWR
round holes.

Software vendors may attempt to address the control issue by providing an

open-source license to clients. This solution, however, only enhances the illusion.
Offering millions of lines of source code does not provide real control; it simply
moves the burden of complex source forking/merging issues, security and quality
control to clients. This can be extremely burdensome to prepaid card issuers
and program managers, where card brand mandates require the deployment of
multiple new releases every year.

$QRWKHUVLJQL¿FDQWLVVXHZLWKDQLQKRXVHVRIWZDUHVROXWLRQLVVFDODELOLW\7KHVH
software systems are not designed for the level of aggregate transaction
volume that a prepaid processing system experiences, with the majority of them
processing relatively low volume credit and debit card portfolios. Due, however,
to the seasonal- and/or marketing-focused nature of some prepaid products, even
relatively small portfolios of prepaid cards can experience enormous transaction
volume spikes. If transaction management is left to an external relational database
management system, as is often the case, such platforms are expensive to scale
to any magnitude and are ultimately destined to fail.

In the end, a straight software solution to prepaid card processing can easily
be the worst of both worlds: the lack of control of an outsourced third party
processor arrangement combined with the technical and operational cost of an
internal build.

III. TxVia’s Platform as a Service (PaaS) Delivery Model

TxVia offers a new approach to prepaid card processing–platform as a service
(PaaS)–changing the paradigm and allowing issuers and program managers
to remove technology-related hurdles to growth and success. TxVia’s PaaS
approach to prepaid card processing better manages the complexities
of prepaid across the various products, verticals, industries, organizations
and channels.

© 2008 TxVia, Inc. All Rights Reserved. 6

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

With TxVia’s PaaS delivery model, prepaid card processing can be completely
outsourced to TxVia or deployed entirely inhouse by the client, as well is in various
K\EULGIRUPVWKDWFDQHYROYHRYHUWLPH5HJDUGOHVVRIWKHFRQ¿JXUDWLRQLVVXHUV
DQG SURJUDP PDQDJHUV XVLQJ 3DD6 UHDOL]H VLJQL¿FDQW EHQH¿WV 3DD6 RIIHUV DQ
online platform, complete with the application development, data storage and
other tools required to run multi-tenanted, massively scalable operations.

2XUVLVWKH¿UVWDQGRQO\3DD6VROXWLRQIRUWKHSUHSDLGFDUGLQGXVWU\

We implement PaaS with a model-driven architecture (MDA), and offer a graphical

integrated development environment (IDE) and fully documented template library
ZLWKZKLFKZHRUDWWKHLURSWLRQRXUFOLHQWVFDQTXLFNO\DQGHI¿FLHQWO\FUHDWH
KLJKO\ FXVWRPL]HG SURFHVVLQJ SODWIRUPV WR PHHW WKH VSHFL¿F QHHGV RI HDFK RI
our clients. Clients may completely outsource their processing to TxVia or bring
it entirely in-house. Either way, the limitations of platforms shared with other
organizations and products are eliminated, as well as the challenges associated
with in-house software solutions.

The IDE can be used to describe (or “model”) a fully integrated, end-to-end
prepaid card processing system. Starting with our template library, TxVia or a
client can model all individual business requirements with the IDE, including:

:: 'DWDÀRZV
:: :RUNÀRZV
:: Service level agreements (SLAs)
:: Cardholder, customer service, administrative and other Websites
:: Web services APIs

© 2008 TxVia, Inc. All Rights Reserved. 7

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

Once completed, models automatically generate custom processing platform

software in executable object code form. TxVia either can host the newly built
platform as a separate operating stack within our data centers, or our clients–or a
third party hired by the client–can perform this function. Ongoing, either we or our
clients model new features and functionality, facilitating the rapid introduction of
new capabilities when they are needed. While enhancements to the shared code
base approach used by other processors are driven via a single development and
QA pipeline, TxVia allows for multiple pipelines to be used—driven by individual
client priorities and engagement.

The IDE also can be utilized by us and our clients to monitor the runtime
performance of the platform in a visual, intuitive manner—providing never before
available transparency into a client’s platform and its operations. Data grids
complete TxVia’s PaaS offering.

In addition, TxVia offers a complete set of services to support prepaid card platforms
and programs, including: (a) hosting and platform services such as technical and
¿QDQFLDORSHUDWLRQVEPDQDJHGVHUYLFHVVXFKDVFXVWRPHUVHUYLFHIUDXGDQGULVN
management; (c) switch services, facilitating access to third-party functions such
as issuing and loading; (d) and professional services. As a result, TxVia provides a
far better outsourcing opportunity for issuers and program managers on a third-
party processor basis, with less integration complexity, systems requirements and
operational headaches.

TxVia believes a PaaS delivery model provides a fundamental decoupling of

the technology, product and operations value chain so that overall complexity
is reduced and organizational parallelism is increased; thereby providing the
scale and quality the industry demands at this stage of its development and
in the future.

Payment System Technical Custom, Segregated

Business Requirements Implementation Processing Platform

‡8VH,'(WR ‡0RGHOVFRPSLOHG ‡&RPSOHWHHQG

GH¿QHEXVLQHVV directly to to-end prepaid
PaaS Delivery Model

requirements in executable code card processing

processing models as
FDOOÀRZVZRUNÀRZV ‡'HSOR\HGDFWLYH ‡3URFHVVLQJSODWIRUPV
GDWDÀRZVHWF active to data grid are customized and
segregated and
‡8VHGIRULQLWLDODQG ‡9DU\LQJWDUJHW contain all necessary
ongoing development architectures requirements but no
supported unnecessary ones
‡:HEEDVHG
application ‡3UHYHQWV ‡&OLHQWVPDLQWDLQ
enabling distributed obsolescence as competitive
development technology improves advantages and
networks through recompilation improve IP protection
of models, avoiding
‡)DFLOLWDWHVPRGHO replatforming cycle ‡,QKRXVHRXWVRXUFHG
GULYHQFRQ¿JXUDWLRQ and hybrid
minimizing reliance deployments
on data-driven
FRQ¿JXUDWLRQ
‡8VHGWRYLVXDOL]H
runtime platform

© 2008 TxVia, Inc. All Rights Reserved. 8

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

,97HQ6SHFL¿F/LPLWDWLRQVRI6DD6DQG,Q+RXVH
6RIWZDUH%HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
%HORZ DUH WHQ VSHFL¿F OLPLWDWLRQV WKDW UHVXOW IURP WKH FXUUHQW 6DD6 DQG LQKRXVH
software delivery models for prepaid card processing described above. Also included
are the ways in which TxVia overcomes these limitations with PaaS and the resulting
EHQH¿WVWRLVVXHUVDQGSURJUDPPDQDJHUV

 /LPLWDWLRQVRQUHOLDELOLW\DQGVFDODELOLW\RISODWIRUPV
Currently, many prepaid cards do not function at appropriate service levels.
As portfolios continue to grow, the ability for platforms to scale is seriously
in question, and there is a high likelihood that reliability of platforms will
deteriorate further.

The reliability and scalability challenges result, in part, from unnecessary

complexities in shared platforms–whether deployed by third-party processors as
SaaS or as part of in-house software solutions–where any given client uses a
fraction of the platform’s capabilities. Processors commingle different prepaid card
applications on a single processing system to the detriment of each application.
As a result, one type of prepaid card or issuer/program manager is unnecessarily
burdened with the technical and operational complexities required by another.

For example, processors that are using a single processing system for millions,
if not billions, of settlement dollars each year in support of a general purpose
UHORDGDEOH*35FDUGSRUWIROLRIRURQHFOLHQWIUHTXHQWO\¿QGWKHQHHGWRORDGODUJH
numbers of gift cards onto the same platforms in short bursts (particularly during
the holiday season or as part of marketing and rebate campaigns) for another
client. Not only does this create hurdles in loading gift cards, but the sporadic
loads cause the GPR portfolios to operate at below acceptable levels of service.
2QFH ORDGHG *35 DQG JLIW YROXPH F\FOHV IROORZ VLJQL¿FDQWO\ GLIIHUHQW UHODWLYH
usage patterns, and therefore can interact on a shared platform in detrimental
ways to each other and all other prepaid card products on the platform.

The seasonality of various prepaid card products creates multiple peaks for
processing resulting in further challenges to reliability and scalability. A travel card
(peak in summer holiday season), a gift card (peak in year-end holiday season)
DQG DQ )6$ FDUG SHDN LQ HQUROOPHQW SHULRG LOOXVWUDWH WKH FRQÀLFWLQJ SULRULWLHV
typical of shared platforms.

With a shared third-party processing SaaS solution or in-house software system,

any new functionality introduced for any product or any client is introduced
onto a shared code base. As a result, from time to time, this impacts the ability
for all products and clients to function at acceptable service levels. Similar to the
volume cycle issue described above, product release cycles can interact to the
detriment of all.

© 2008 TxVia, Inc. All Rights Reserved. 9

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

Serious reliability and scalability issues—both third-party processor SaaS solutions

and in-house software solutions—also stem from inherent issues with underlying
technology architectures such as the commonplace reliance on relational database
management systems (RDBMS) to perform online processing. These technical
limitations greatly undermine the scale, functionality and quality of service that
these platforms can reasonably be expected to provide in processing prepaid
cards now and in the future.

The larger an RDMBS gets, the more disk I/O it takes to read and update records
LQWKHGDWDEDVH:KLOHDFOLHQWVSHFL¿FGDWDVWRUHSURYLGHVKLJKSHUIRUPDQFHDQG
reliable response times, larger commingled databases have greater complexity
in the management of data-backups, restores, all archiving processing and
administration take longer causing additional problems in meeting issuer/program
manager and cardholder expectations.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
TxVia’s PaaS delivery model reduces the complexity inherent in each client’s
platform by eliminating any unnecessary functionality; thereby substantially
increasing reliability and scalability.

Where the complexity in any given platform for a client cannot be minimized
VXI¿FLHQWO\ZLWKDVLQJOHSODWIRUPGHSOR\PHQWDVPD\EHWKHFDVHLIDVLQJOHFOLHQW
is processing large volumes of GPR and gift cards, TxVia can deploy more than
one platform per client. As a result, by leveraging the TxVia solution, sporadic
high-volume gift card programs never impact the ongoing functioning of GPR
programs, and any new functionality introduced for one product or client will not
impact another product or client.

Since TxVia manages complexity in models built on a per client/product basis, the
challenges of attempting to manage that complexity in a single shared code base
as is the case with SaaS and in-house software are also removed.

To further enhance platform reliability and scalability, TxVia provides an advanced

data grid-based implementation that can economically scale online processing
capability up to tens of thousands of transactions per second, across terabytes
RIDFFRXQWRQ¿OHGDWD7KHJULGDSSURDFKSURYLGHVSUHGLFWDELOLW\LQWKHVL]LQJRI
processing capacity to meet the needs of a prepaid card portfolio, the ability to
handle peaks and a clear path to cost-effectively increase capacity over time.

 /DFNRIGHYHORSPHQWWUDQVSDUHQF\
There is a considerable lack of transparency in the development of both third-
party processing platforms and in-house software solutions. These systems
are typically the result of a “closed-door” development methodology that
does not allow clients to monitor progress, check correctness or involve
their own technical resource in the process. Even in the rare cases when

© 2008 TxVia, Inc. All Rights Reserved. 10

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

clients are involved in the development process, such as being invited

to daily scrum meetings, it is generally only for the purposes of project tracking,
often on systems outside of the most important core transaction processing
components, with little or no visibility into the actual technical work being done.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
:LWK7[9LD¶V3DD6GHOLYHU\PRGHOFOLHQWSODWIRUPVDUHGH¿QHGZLWKLQ³SURFHVVLQJ
models.” Model developers, within either the TxVia or client organization, can
work together on the same processing model, sharing efforts and enabling
HIIHFWLYHDQGHI¿FLHQWLQWHURUJDQL]DWLRQFRPPXQLFDWLRQDFURVV7[9LDWKHFOLHQW
and relevant third parties. The transparency of this process allows the client to be
more comfortable with the current state of both the platform and any necessary
development effort, vastly improving communication among all parties and
providing higher quality solutions within shorter time frames.

 /DFNRIRSHUDWLRQDOWUDQVSDUHQF\LQDELOLW\
to timely track service level breaches
SaaS and in-house software solutions are opaque with respect to their internal
operations—when performance problems and error conditions occur, they are
GLI¿FXOWWRDQWLFLSDWHGLI¿FXOWWRGLDJQRVHDQGUHTXLUHDQH[WHQVLYHFRRUGLQDWHG
effort across multiple parties to identify the root cause and remediate. This lack
of transparency can lead to extended service outages and an inability to manage
communications effectively with cardholders.

For example, SaaS and in-house software processing systems are not well
GHVLJQHGWRHQVXUHWKDWIDLOXUHVWRPHHWVHUYLFHOHYHOVDUHLGHQWL¿HGDQGUHSRUWHG
LQDWLPHO\IDVKLRQ,WLVW\SLFDOLQWKHLQGXVWU\WRGD\WKDWWKH¿UVWLQGLFDWLRQRID
prepaid card processing issue is the resulting increased call volume in an issuer’s,
program manager’s or processor’s call center. Prepaid cards are already challenged
in acceptance due to the early stage of the market bad or interrupted service can
slow their rate of acceptance, undermining the entire prepaid card industry. In
addition, for an issuer or program manager that offers prepaid cards as part of an
integrated product or service, a negative cardholder experience can have fallout
on its entire relationship with that customer. Existing platforms are generally not
designed from the ground up to meet Service Level Agreements (SLAs)–especially
FOLHQWVSHFL¿F6/$V±DQGSUHVHQWQXPHURXVWHFKQLFDODQGRSHUDWLRQDOLVVXHVLQWKH
tracking, reporting and diagnosis of such issues.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
TxVia is far more transparent in its operations than any SaaS or in-house software
system in market. The TxVia modeling environment can be utilized by us and
our clients to monitor the runtime performance of platforms in a visual, intuitive

© 2008 TxVia, Inc. All Rights Reserved. 11

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

manner—providing never before available transparency into a client’s platform

and its operations.

From an SLA perspective, for example, TxVia provides SLAs as a modeling artifact,
with thousands of SLA monitoring points throughout a typical processing system.
SLA violations are visualized directly within the running model so that issues can
EHTXLFNO\LGHQWL¿HGDQGUHVROYHG

This visualization is not only available to TxVia personnel, but also to the issuers and
program managers, enabling accurate and timely messaging and communication
to cardholders. TxVia eliminates the “black box” nature of processing that exists
today, which gives clients little to no transparency into their processing systems.

 ,QHI¿FLHQWDOORFDWLRQRIUROHVDQGUHVSRQVLELOLWLHV
and inability for issuers and program managers
to take control; lack of sustained utility of
SURJUDPDQGSURGXFWFRQ¿JXUDWLRQVFUHHQV
In today’s prepaid card market, many issuers and program managers want to
undertake greater control over their prepaid card processing platforms, reallocating
UROHVDQGUHVSRQVLELOLWLHVWREHPRUHHI¿FLHQWDQGWRUHGXFHWKHRYHUDOOFRVWVRI
managing a third-party processing relationship.

With the traditional third-party SaaS approach and in-house software systems,
there is little to no ability for issuers and program managers to take practical and
cost-effective control over their platforms so as to have a better allocation of roles
and responsibilities between the issuer and program manager on the one hand
and processor or software vendor on the other. Instead, issuers and program
managers must rely on the “black box” processor or software vendor, where the
vast majority of control resides.

The inability for issuers and program managers to control their platforms means
they are subject to the limitations of the processor or software vendor. Issuers
and program managers, therefore, confront tremendous challenges in attempting
to build and integrate functionality or third-party connections into their programs,
which are frequently critical for prepaid card portfolios. The additional systems
LQWURGXFHGE\LVVXHUVDQGSURJUDPPDQDJHUVFUHDWHDGGLWLRQDOSRLQWVRILQHI¿FLHQF\
and failure, and can require issuers and program managers to maintain extraneous
personnel and systems.

With many SaaS processing environments and software solutions, any program
FRQ¿JXUDWLRQSHUIRUPHGE\WKHLVVXHURUSURJUDPPDQDJHULVW\SLFDOO\GRQHXVLQJ
web interfaces that create, update and delete information from a data-driven options
management system. Such an approach can work well in the short term, but as
features are added and the number and variety of clients increase, the complexity
of developing, testing and managing such a system explodes. Simply changing

© 2008 TxVia, Inc. All Rights Reserved. 12

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

an option in a data-driven environment can cause new untested code paths to

be utilized within the platform, resulting in reduced performance and unexpected
results. In order to be PCI-DSS compliant, developers and QA personnel typically
do not have the opportunity to test production option and data sets with new code.
Adding new features becomes increasingly cumbersome, reducing time-to-market
and increasing change management risk. This exponential increase in complexity
management ultimately puts an upper bound on the architectural and operational
scale software and SaaS vendors can achieve, and reduces the long-term utility of
their options management systems to issuers and program managers.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
Using the TxVia IDE and templates, a client can choose to take control over a
range of functions and third-party relationships including:

:: feature/functionality
:: FRQ¿JXUDWLRQ
:: product development and release timing
:: run-time instrumentation and visualization
:: infrastructure and service levels
:: third-party vendors

At TxVia, we offer a range of options for clients to deploy and manage platforms
either on an outsourced basis or internally, as well as hybrid options—all of which
FDQ HYROYH RYHU WLPH DFFRUGLQJ WR D FOLHQW¶V QHHGV 7KH UHVXOW LV D VLJQL¿FDQWO\
better allocation of roles and responsibilities and the ability of TxVia to vest
differing degrees of control with clients that choose to manage these aspects of
the solution.

We categorize the types of control we offer into Platform Creation and Enhancement;
&RQ¿JXUDWLRQ2SHUDWLRQVDQG7KLUG3DUW\,QWHJUDWLRQ

:: Platform Creation and Enhancement. Instead of relying on TxVia to model

a client platform, an issuer or program manager can utilize the TxVia IDE and
templates to create, manage and enhance their platform as and when it wishes.
TxVia can assist in the task of transforming a client’s business requirements
into models, or a client can take complete control over the introduction of new
features and functionality for its platform.
:: Configuration.  7[9LD SURYLGHV D PRGHOGULYHQ FRQ¿JXUDWLRQ PDQDJHPHQW
system that utilizes automated, rigorous continuous integration testing to
reduce risk and increase quality. All option changes entered into the web-
EDVHG ZRUNÀRZ PDQDJHPHQW V\VWHP JR WKURXJK D EDUUDJH RI FRPSOLDQFH
FHUWL¿FDWLRQXQLWDQGLQWHJUDWLRQWHVWVEHIRUHEHLQJGHSOR\HGLQWRWKHSURGXFWLRQ
environment. In addition, model developers and QA personnel can work with

© 2008 TxVia, Inc. All Rights Reserved. 13

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

SURGXFWLRQ FRQ¿JXUDWLRQV ZKLOH PDLQWDLQLQJ 3&,'66 FRPSOLDQFH 7KH 7[9LD

VROXWLRQDOVRSURYLGHVIRUGDWDGULYHQFRQ¿JXUDWLRQLQWKHKDQGIXORIVLWXDWLRQV
where the business case warrants, but TxVia recommends keeping this to a
minimum for the reasons noted above.
:: Operations. Once a client model is compiled into the target processing
platform, the executable object code can be deployed into an environment of
the client’s choosing. While TxVia can host the platform, an issuer or program
manager can opt to host its platform in-house or have another third party
host it. Also, issuers and program managers are no longer locked into the
operational constraints of a third party processor. Now they can choose
where and when they deploy their platform, and control who operates the
platform and how.
:: Third Party Integration. With TxVia, clients can choose to control
any and all third-party relationships. In addition, clients can integrate
into their own servicing centers. Alternatively, an issuer or program
manager may choose to use TxVia’s switch services for turnkey access
to key integrations into third parties such as payment networks,
ORDGQHWZRUNVFDUGSURGXFWLRQDQGIXO¿OOPHQWIDFLOLWLHVDQGLVVXLQJ¿QDQFLDO
institutions.

5. Inability to appropriately manage costs

With SaaS and in-house software solutions, there are serious limitations on the
ability for an issuer or program manager to appropriately manage their total
cost of ownership (TCO) in operating a prepaid card portfolio. These limitations
result from:

:: Issues with scaling a platform such as the inability to effectively integrate

the solution with existing infrastructure leading to unmanageable
data synchronization issues, API volume and overall system complexity
at scale
:: Inability to properly allocate roles and responsibilities, and for a client to take
a meaningful degree of control
:: Inability to scale solution in an economically predictable manner, often
requiring a series of large, complex and expensive re-architecting efforts to
scale to the next level
:: Software tuning that does not yield appropriate results in performance,
resulting in escalating costs for hardware installations (faster and bigger
CPU’s, memory needs and disk technologies can run up costs out of issuers’
and program managers’ control)

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
7[9LDRIIHUVDUDSLGSURFHVVIRUGH¿QLQJDQHQWLUHSUHSDLGSURFHVVLQJSODWIRUP
based upon an individual client’s needs, and managing the processing

© 2008 TxVia, Inc. All Rights Reserved. 14

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

platform on an ongoing basis. The TxVia PaaS delivery model minimizes

WKHXVHRIDFOLHQW¶VLQWHUQDOUHVRXUFHV¿WVQDWXUDOO\LQWRH[LVWLQJLQIUDVWUXFWXUH
avoids data synchronization work and typically requires substantially
less resource than deploying and working with traditional third-party shared-
platform processors.

For example, typically when an issuer or program manager requires

new functionality or integration with a third party, the processor is too
burdened with other projects or system complexity to complete the project
on a timely basis. It is much simpler for TxVia, or the issuer/program manager,
to extend a TxVia model than create a whole new system/integration/deployment
infrastructure to make up for missing functionality at a third-party processor. The
underlying model-driven architecture of the TxVia PaaS delivery model also allows
an economically predictable method of scaling to support the exponential volume
increases some portfolios require.

The result is more competitive programs that are quicker to market with
substantially lower TCO.

6. Inability to timely introduce product enhancements;

inability to protect intellectual property
The prepaid card industry is in early stages of market maturity. To keep pace,
issuers and program managers must introduce new features and functionality on
a consistent basis to create the best prepaid products for the marketplace as well
as differentiate their offerings from those of their competitors.

A shared platform, whether provided as a SaaS or in-house software solution,

must be a “jack of all trades” and ends up being a master of none. For example,
in shared platform environments, a client feature or functionality request might
KDYHDQDUFKLWHFWXUDORUGHVLJQFRQÀLFWZLWKRWKHUH[LVWLQJIXQFWLRQDOLW\XVHGE\
other clients or products.

Enhancements to a shared code base must be driven via a single development/

QA pipeline, leading to all enhancements being tightly coupled across products
and clients.

With enhancements needing to be made by a third-party processor or software

vendor, any new capabilities go into a shared environment where it is challenging,
if not impossible, to appropriately maintain any differentiation between the
intellectual property of a client and the processor or software vendor. Since
the code is embedded into the processing system software, typically the new
functionality becomes fungible with the rest of the platform and is offered to
any given client’s competitors by the processor. To overcome this issue, in some
cases third-parties offering SaaS or in-house software solutions offer exclusivity

© 2008 TxVia, Inc. All Rights Reserved. 15

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

for functionality, but this is typically limited to relatively short periods of time,
ranging from six to 12 months.

Software vendors have even larger challenges in providing their clients updated
systems, as there is no central systematic method for managing updates
such as that employed with PaaS solutions. Each client update represents a
VLJQL¿FDQW,7SURMHFWIRUWKHVRIWZDUHYHQGRUWKXVIRUFLQJWKHVRIWZDUHYHQGRU
to aggressively move client customizations into the “base” platform to allow
their business to scale.

The alternative approach of an issuer or program manager building functionality

itself to protect its competitive advantage adds additional cost and increases the
likelihood of reliability and scalability issues.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
With our use of MDA, TxVia captures business requirements in models, not in code
bases. Issuers and program managers can take control over models to introduce
QHZIXQFWLRQDOLW\DQGKDYHWKRVHPRGHOVUHPDLQVSHFL¿FWRWKHLUSODWIRUPV7[9LD
templates employ a plug-in architecture, so clients can readily extend off-the-
shelf functionality in a simple and manageable way. This sustains their competitive
advantages and improves protection of their intellectual property in an industry
that is consistently introducing new and innovative capabilities.

The split between the business and technical aspects of a system

also allow each to evolve at its own pace, vastly increasing the speed
DQG HI¿FLHQF\ RI ERWK %XVLQHVV UHTXLUHPHQWV FDQ EH PRGHOHG DQ RUGHU
of magnitude quicker (we estimate at least 10x) than would be possible
using a traditional software development approach (see Star integration
example in Section (V) below), and technical architectural changes
can be made on their own merits, independent of the concerns of
business logic.

 /LPLWDWLRQVRQDELOLW\WRUHDGLO\LQWHJUDWH
into key products and services providers
As the prepaid market has become more sophisticated, the demand for more
services and connections has increased, with new and innovative vendors
offering products such as SMS transaction and balance updates, cardholder
LGHQWLW\ YHUL¿FDWLRQ IUDXG PDQDJHPHQW ELOO SD\PHQW SHUVRQWRSHUVRQ
payments and more.

Once an issuer or program manager wishes to extend internationally to launch

products that are issued and operate in other countries, there may also
EHDUHTXLUHPHQWWRLQVWDOODQGFHUWLI\ZLWKUHJLRQDORUFRXQWU\VSHFL¿FSD\PHQW
networks. Connecting and integrating to these services and networks has,
until now, been in lockstep with the limitations of shared platform processors.

© 2008 TxVia, Inc. All Rights Reserved. 16

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

In contrast, software vendors often see these types of integrations as “base”

platform enhancements, which results in longer lead times, far reaching changes
in their platform, lack of client control, and ultimately increased complexity and
decreased stability that affects the overall client base negatively.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
$Q\QHWZRUNLQWHJUDWLRQVXFKDVLQWR9LVDRU0DVWHU&DUGLVDGLI¿FXOWVRIWZDUH
development effort to implement in a scalable, secure and functionally correct
way. There can be many variations across these integrations; managing these
LQDVRIWZDUHHFRV\VWHPLVDVLJQL¿FDQWXQGHUWDNLQJ+RZHYHUWKH\DOVRH[KLELW
DJUHDWGHDORIFRPPRQDOLW\LQDUHDVVXFKDVGDWDÀRZDUFKLWHFWXUHVHFXULW\
and messaging.

The TxVia IDE is designed so these considerations are built into the modeling
HQYLURQPHQWZLWKHQRXJKÀH[LELOLW\SURYLGHGVRDOOYDULDWLRQVFDQEHH[SUHVVHG
QDWXUDOO\DQGDVVLPSO\DVSRVVLEOH7KLVUHVXOWVLQDQHI¿FLHQWGHVFULSWLRQRID
network integration that is quick to develop, test, deploy and more cost effective
to manage. A developer does not need to be concerned with the complex
architecture, security and scale concerns that otherwise would dominate the
development effort and is free to focus on describing the relevant functional
UHTXLUHPHQWV 7KH GHYHORSHU FDQ KDYH FRQ¿GHQFH WKDW WKH PRGHO FRPSLODWLRQ
process will incorporate the best available technologies and architectures in the
generated object code.

The main implementation artifact of the TxVia modeling environment is executable

Data Flow Diagrams (DFDs). These DFDs allow TxVia or our clients to more naturally
describe and implement system integration tasks, where the focus is typically on
data sources, sinks and transformations. This same approach is often used in ETL
(Extract, Transform & Load) tools, for the same reason—multiple systems need to
be integrated for the purposes of moving, analyzing and warehousing data.

Because integrations are modeled within segregated client processing models,

they do not burden a shared code base with complex and varied integration code.
This provides a more manageable solution in the long run than otherwise available,
VLQFHHDFKDGGLWLRQDOLQWHJUDWLRQZLWKLQDVLQJOHFRGHEDVHFDQVLJQL¿FDQWO\LQFUHDVH
overall complexity (design/operational/QA/management).

 /LPLWDWLRQVRQDELOLW\WRGHSOR\
platforms and programs internationally
While existing prepaid card processing systems may be internationalized with
multicurrency and multilingual capabilities (although not all third-party processors
have these capabilities), the greatest challenge in deploying a prepaid card
processing system internationally is tied to the ability to ensure the system is

© 2008 TxVia, Inc. All Rights Reserved. 17

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

compliant with local laws and regulations and can be readily integrated into local
and regional payment schemes and networks.

The ability to deploy and manage multiple systems installed in different geographic
regions and time zones is tremendously challenging for existing third-party
processors with large shared platforms and for in-house software vendors. The
shared platform approach that third-party processors use and the challenges of
managing an in-house software solution, combined with the lack of any integration
modeling solution, create deployment and architectural problems that limit the
technical and operational capabilities needed by an issuer or program manager to
expand aggressively into international markets.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
The TxVia PaaS solution has full multi-currency support, including support for
FOLHQWGH¿QHG QRQPRQHWDU\ FXUUHQFLHV VXFK DV SRLQWV RU PLOHV 7KLV FDSDELOLW\
H[WHQGVIURPWKHFRUHDFFRXQWRQ¿OHWUDQVDFWLRQSURFHVVLQJWR,95DQG:HEVLWH
interfaces. In addition, TxVia platforms are fully internationalized (I18N) so they
can easily be localized across the countries and regions in which the issuer’s or
program manager’s card portfolio operates.

7[9LD¶VGHOLYHU\PRGHOIRUSUHSDLGFDUGSURFHVVLQJRIIHUVWUHPHQGRXVEHQH¿WV
for international implementations that simply are not attainable with any
other processing system. TxVia’s tools, templates and generated platforms
are designed to be deployed globally. From extensive internationalization and
ORFDOL]DWLRQVXSSRUWWRGHSOR\PHQWÀH[LELOLW\VHHDERYHWRLQWHJUDWLRQHDVH
(see (7) above) required for a truly global platform, TxVia’s offering represents
WKH¿UVWRILWVNLQGLQWKHSUHSDLGFDUGLQGXVWU\

7KHGHSOR\PHQWDQGDUFKLWHFWXUDOÀH[LELOLW\RI3DD6WKDW7[9LDEULQJVWRLVVXHUV
and program managers can be leveraged in a number of ways for processing in
multiple countries. Per-country and/or time zone-related platforms can be created
and managed easily in a loosely coupled fashion. Or the issuer or program manager
can process in all markets with a single platform, optionally pinning data within a
single global grid to servers resident in different countries to adhere to local data
SURWHFWLRQSULYDF\ODZVDQGUHJXODWLRQVHWF7KLVW\SHRIÀH[LELOLW\LVQRWRIIHUHG
today by third party processors offering SaaS or in-house software providers, and
severely limits their ability to expand into these markets.

9. Obsolescence and limitations on life of platforms

Processing systems are typically very large software systems, often with
millions of lines of code. The size of these systems present great challenges in
evolving them effectively over time to best make use of emerging technologies,
architectures and ideas. This issue is compounded by the relative longevity of card
processing systems in general. In the credit and debit card worlds, the widespread

© 2008 TxVia, Inc. All Rights Reserved. 18

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

use of Tandem and IBM mainframe-based transaction processing systems in the

1970s and 1980s has, despite the inherent cost of these solutions, paid long term
dividends. In fact, these “big-iron” environments are still well supported and will
continue to exist for decades. The underlying server-based technologies used
E\WKH¿UVWZDYHRISUHSDLGFDUGSURFHVVLQJV\VWHPVKRZHYHUGRQRWRIIHUWKH
same long-term vendor support, which has become a driving factor in the re-
platforming initiatives being undertaken or considered across the industry.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
7[9LDEULQJVDPRGHOGULYHQ3DD6VROXWLRQWRSUHSDLGSURFHVVLQJ&OLHQWVSHFL¿F
processing platforms are systematically generated from processing models in
their entirety, allowing new technologies and architectures to be leveraged with
a straightforward recompilation of the model. This combines the evolutionary
EHQH¿WV RI ORQJOLYHG PDLQIUDPHEDVHG VROXWLRQV ZLWK WKH IHDWXUH IXQFWLRQDOLW\
and economics of a modern systems architecture.

&KDOOHQJHVZLWK3&,'66FRPSOLDQFH
In an Internet-connected world, PCI-DSS compliance is an important consideration
for all card processing systems. Many processing systems, including those in
the prepaid card industry, were designed and built before PCI-DSS existed or
was required, and have struggled to keep up with these evolving requirements.
6SHFL¿FDOO\WKHXVHRIHQFU\SWLRQZLWKLQWKHVHV\VWHPVKDVEHHQZHDNRUQRQ
H[LVWHQW DQG GLI¿FXOW WR UHWUR¿W 7KLV KDV LQFUHDVHG WKH RSHUDWLRQDO FRVWV RI
running these systems in a PCI-DSS compliant manner.

These issues are compounded by the fact that over the past several
years, major security breaches in the payments industry have occurred on
D UHJXODU EDVLV 7KLV KDV OHG WR FKDQJHV WR WKH 3&,'66 VSHFL¿FDWLRQ
creating even greater challenges for legacy platforms to keep pace with the
latest requirements.

 %HQH¿WVRI7[9LD¶V3DD6'HOLYHU\0RGHO
TxVia’s PaaS delivery model supports PCI compliance in a number of ways, most
importantly via model compilation that allows platforms to adhere to the latest
standards via a straightforward recompilation and redeployment process. The
current implementation architecture uses AES-256 for all data management,
providing the highest available level of encryption for all data within the platform.
As new encryption standards are mandated, platforms can be updated in a
timely manner. This greatly reduces the PCI-DSS related operational costs of the
platform, from storage device management to network security. In addition, all
model changes are tracked in a PCI-compliant manner, and the entire tool chain
is PA-DSS compliant.

© 2008 TxVia, Inc. All Rights Reserved. 19

 WHITEPAPER & TXVIA | Prepaid Card Processing with a
www.txvia.com

SOLUTION OVERVIEW | Platform-as-a-Service (PaaS) Delivery Model

JUNE | 2008

9 ([DPSOHRI(I¿FLHQF\DQG(IIHFWLYHQHVVRI7[9LD¶V3DD6
Delivery Model—Integration to Star® Network
Integrating a payment platform into a new payment network can be a complex project,
ZLWKH[WHQVLYHDQDO\VLVGHYHORSPHQWWHVWLQJDQGFHUWL¿FDWLRQSURFHVVHV6HHPLQJO\
minor, subtle differences in message sets can create ripples across the underlying
core processing system. In a traditional software environment, the process can take
three to six months to integrate a new payment network in such a way to ensure
correctness, performance and stability.

The creation of TxVia’s Star network integration template involved a fraction of this
WLPH 2XWVLGH RI WKH LQLWLDO DQDO\VLV WKH RYHUDOO LPSOHPHQWDWLRQ DQG FHUWL¿FDWLRQ
process occurred over the course of one week–an order of magnitude improvement
LQ GHYHORSPHQW WHVWLQJ DQG FHUWL¿FDWLRQ VSHHG 6WDU KDG UHVHUYHG WKUHH ZHHNV IRU
FHUWL¿FDWLRQDORQHDVLVVWDQGDUGIRUQHZSODWIRUPVMRLQLQJWKHLUQHWZRUN'HVSLWHWKH
high speed development process, the end result was a highly scalable, manageable
and self-documented integration template.

© 2008 TxVia, Inc. All Rights Reserved. 20