ISO 8583, transaction processing, and issuing prepaid cards
David Barrett
archives (as well as through Andy's blog). However, I'm still having
some trouble piecing together answers to the following questions. Can
you please do me the great favor of helping me fill in the blanks?
(As quick background, I'm researching the viability of creating a new
transaction processor for prepaid cards on the MasterCard network.
I'm familiar with what this involves at a high level -- BIN
sponsorshop, MSP certification from MasterCard, PCI compliance, BSA,
KYC, OFAC, etc -- but I'm struggling to get detail about how this
translates into technical requirements.)
1) As a transaction processor will I communicate exclusively with my
issuing bank, or will I also communicate with MasterCard directly?
2) What is the physical infrastructure typically used to communicate
with each party? Is it some sort of leased IP line, or are encrypted
internet connections adequate?
3) Is ISO 8583 only used between me and MasterCard (authorization,
settlement, chargebacks), or is it also used between me and the
issuing bank?
4) Assuming we only intend to interface with a single network
(MasterCard), is the ISO 8583 interface well defined and relatively
constrained? Or is there a lot of variation in ISO 8583
implementations across different merchant banks, meaning we need to
implement a bunch of separate per-merchant-bank interface logic? Who
do I speak with at MasterCard and what document do I ask for that
spells out the MasterCard-specific variant of ISO 8583?
5) Am I correct in assuming that each issuing bank has their own
custom interface for card issuance and cardholder/settlement account
management? Are these all wildly unique between banks, or are they
typically variations on a single protocol? Is that protocol ISO 8583
or something else? In general, who should I ask to speak with at the
issuing bank, and what document/specification should I ask for? (I'm
guessing it's some document that has a particular common name; what is
it commonly called?)
6) Does the ISO 8583 standard specify purely "on the wire"
communication, or does it also define the internal state machines and
processing logic that I would be expected/required to implement?
7) Which of the above bullets are handled by jPOS? I'm guessing it
handles (4) at the very least; does it also handle (5 -- issuing bank
interface) and (6 -- transaction state machines?)
8) Is there a "hosted" jPOS service available that handles all the
physical infrastructure so we needn't do it ourselves?
As for why we're considering an in-house processing solution, we've
been disappointed with the constraints, timeliness, and cost of the
many prepaid transaction processors we've spoken with. (We have some
atypical requirements that don't quite mesh with their typical
implementations.) It's still a long-shot to do it ourselves, but we'd
like to investigate the option deeply before we discount it out of
hand.
Thanks, I appreciate your help!
-david
PS: Is the http://www.fdms.com/nojs.asp link working for anybody
else? I've tried both FireFox and IE -- with JavaScript enabled --
but I keep getting the following error message:
"Problem Detected
This web site requires the use of Internet Explorer ONLY with
JavaScript enabled. Please either enable JavaScript on your browser or
switch to Internet Explorer before continuing.
Thank you."
Andy Orrock
That's a great set of questions. See my comments below marked 'AAO'.
Also, re. the FDMS spec site, it does work - I just re-validated this
address in IE & it works perfectly for me:
Andy Orrock
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
> Behalf Of David Barrett
> Sent: Friday, November 23, 2007 7:10 PM
> To: jPOS Users
> Subject: ISO 8583, transaction processing, and issuing prepaid cards
>
>
> Hello, I'm very excited to find this list and read through the
> archives (as well as through Andy's blog). However, I'm still having
> some trouble piecing together answers to the following questions. Can
> you please do me the great favor of helping me fill in the blanks?
>
> (As quick background, I'm researching the viability of creating a new
> transaction processor for prepaid cards on the MasterCard network.
> I'm familiar with what this involves at a high level -- BIN
> sponsorshop, MSP certification from MasterCard, PCI compliance, BSA,
> KYC, OFAC, etc -- but I'm struggling to get detail about how this
> translates into technical requirements.)
>
> 1) As a transaction processor will I communicate exclusively with my
> issuing bank, or will I also communicate with MasterCard directly?
>
AAO: Typically an issuing bank has a transaction processing partner that
would act as a payment gateway for you. Here are two examples:
a) We have a large Acquirer-side client whose sponsoring bank is Chase.
They have a relationship with FDR, so the Acquirer uses the FDR North
interface as a gateway to route Visa, Mastercard, Debit, EBT and Discover
and AMEX to their respective issuers.
b) We have a MasterCard prepaid card issuer whose sponsoring bank is a small
institution in Texas. That bank has a relationship with Elan Financial
Services (a division of US Bank - see http://www.elanfinancialservices.com/)
which gateways transactions to them as issuer.
Only very large acquirers and issuers make direct connections to MasterCard
and Visa.
> 2) What is the physical infrastructure typically used to communicate
> with each party? Is it some sort of leased IP line, or are encrypted
> internet connections adequate?
>
AAO: Always a leased TCP/IP connection.
> 3) Is ISO 8583 only used between me and MasterCard (authorization,
> settlement, chargebacks), or is it also used between me and the
> issuing bank?
>
AAO: See early answer re. the role of gateways. Your issuing bank will
bring a gateway partner to the table. You will talk to that gateway via
ISO8583. NOTE: ISO8583 refers to OLTP auth-level traffic only. Some
processors also have settlement files and acknowledgement files. These are
not ISO8583 entities. First, they're batch. Second, there's no standard.
FDR North, for example, has a proprietary file format called PTS. I'm
implemented dozens of the batch side of things. They're all over the map.
> 4) Assuming we only intend to interface with a single network
> (MasterCard), is the ISO 8583 interface well defined and relatively
> constrained? Or is there a lot of variation in ISO 8583
> implementations across different merchant banks, meaning we need to
> implement a bunch of separate per-merchant-bank interface logic? Who
> do I speak with at MasterCard and what document do I ask for that
> spells out the MasterCard-specific variant of ISO 8583?
>
AAO: You approach your issuing bank, find out how they'll get transactions
to you, and ask for that gateway spec. As an issuer, you'll get
transactions through 1 funnel like that.
> 5) Am I correct in assuming that each issuing bank has their own
> custom interface for card issuance and cardholder/settlement account
> management? Are these all wildly unique between banks, or are they
> typically variations on a single protocol? Is that protocol ISO 8583
> or something else? In general, who should I ask to speak with at the
> issuing bank, and what document/specification should I ask for? (I'm
> guessing it's some document that has a particular common name; what is
> it commonly called?)
>
AAO: As noted in the previous answer, there's no standard on the settlement
side. At all. If you're talking to a competent issuing/sponsoring bank,
they should be able to provide you with the key triumvirate of docs you'll
need:
a) The Auth spec
b) The Settlement spec
c) The Telecom spec
> 6) Does the ISO 8583 standard specify purely "on the wire"
> communication, or does it also define the internal state machines and
> processing logic that I would be expected/required to implement?
>
AAO: The standard describes the options by which fields and messages can be
constructed. An organization like FDR (AMEX, Elan, etc.) then implements
the standard in a particular way, ie, determines BCD vs. Display approach,
chooses fields in play, message set, etc. Other than dictating to you
certain "got to do" things (like dictating the fields in a reversal that are
used to match to the original), there's no processing logic specified.
> 7) Which of the above bullets are handled by jPOS? I'm guessing it
> handles (4) at the very least; does it also handle (5 -- issuing bank
> interface) and (6 -- transaction state machines?)
AAO: jPOS does not handle Settlement out of the box, but if you read the
Real Systems Do Extracts posts in my blog, you know that you can build an
Extract. I've also built Settlement/posting applications in support of a
prepaid vendor like yourself. That was sort of an ad-hoc thing. Alejandro
has productized a lot of those concepts in his MiniGL and jCard project
work.
http://www.andyorrock.com/paymentsystems/2007/11/reconid-500.html
>
> 8) Is there a "hosted" jPOS service available that handles all the
> physical infrastructure so we needn't do it ourselves?
>
AAO: The solutions I've had my hands in to date have been deployed at
client sites.
David Barrett
1) As a small transaction processor I will generally not talk to the
bank or network directly. Rather, I will talk to the bank's "gateway
partner".
2) I will generally communicate with the gateway partner in at least
two formats:
- OLTP (online transaction processing), aka "auth-level"
communications happen via ISO 8583
- Batch processing be done with "authorization files" and "settlement
files", both of which are proprietary
3) In the case of US Bank, the gateway provider is Elan Financial
Services.
4) The holy triumvirate of documents I want are the "auth",
"settlement", and "telecom" specifications. These will be provided to
me by the bank's gateway partner, and not the bank (ie, by Elan, and
not by US Bank). I'm guessing each document covers the following:
- Auth spec: Defines the authorization file format I'll send to the
gateway partner
- Settlement spec: Defines the settlement file format I'll send to the
gateway partner
- Telecom spec: Defines the specific variant of ISO 8583 I'll use to
communicate with the gateway partner
Ok, this is extremely helpful. Thank you. A couple followup
questions:
a) What exactly does the bank's "gateway partner" do (eg, Elan
Financial, in the case of US Bank)? Are they, as the name implies, a
stateless middleman who merely transforms and funnels all external
messages into a single format for my consumption and processing? Or
do they actually perform operations upon those transactions based upon
some database of card/account state that they maintain? I'm guessing
(hoping) it's the former.
b) You mention a "gateway spec" above; is this different than the
triumvirate? Or does the gateway processor ingest the triumvirate and
instead publish to me a single unified "gateway interface" that I
implement?
c) By what interface would I typically perform the non-transaction
operations such as issuing a new card number, loading funds onto the
card, and canceling the card? (I realize I'll have separate
interfaces with card manufacturing, personalization, and fulfillment
bureaus, but for this question I'm specifically referring to the other
digital operations.) Are these performed through the authorization/
settlement files, or is this another interface entirely? If so, is it
directly with the bank, or also through the gateway partner (eg,
Elan)?
d) If the transaction processing logic isn't defined by ISO 8583,
where is it defined? For example, I'm assuming there are rules
specifying what is or is not allowed by the network (eg, I'm guessing
it would be forbidden to arbitrarily decline all transactions with an
odd-valued amount). What is the name of the document that spells this
out in detail? Should I ask MasterCard, Elan, or US Bank to get it?
e) If we are responsible for hosting jPOS on our own servers and
equipment, I expect we will be required to undergo rigorous
certification by MasterCard. I'm familiar with the logical and
physical requirements for MasterCard manufacturing and
personalization; who should I talk with at MasterCard to learn
physical/logical security requirements for transaction processing, and
what should I ask them?
Finally, from the 30,000 foot view, what are the steps of getting up
and running with a jPOS installation for an open-loop prepaid card
program? (For the sake of argument using Elan and US Bank as
examples.) Please correct the following list:
1) Obtain BIN sponsorship from US Bank
2) Obtain the auth/settlement/telecom specs from Elan Financial (or
gateway spec?)
3) Establish 2+ redundant datacenters with leased TCP/IP lines to 2+
Elan Financial datacenters
4) Install jPOS + miniGL
5) Customize to taste
6) Integrate with card manufacturing/personalization/fulfillment
bureau interfaces
7) Integrate with ?? interface for card issuing / activation /
canceling
8) Generate nightly (?) authorization and settlement files and send to
Elan
In this scenario, jPOS would be on the "front line" communicating with
Elan, both for OLTP authorization traffic as well as batch
processing / extract generation. miniGL would provide account
management for the prepaid cards themselves. We would customize these
with our own custom business logic as necessary, as well as to
interface with physical card production and fulfillment. Does this
sound about right?
Thanks for all your help.
-david
Andy Orrock
See comments below.
Andy Orrock
> -----Original Message-----
> From: jpos-...@googlegroups.com [mailto:jpos-...@googlegroups.com] On
> Behalf Of David Barrett
> Sent: Saturday, November 24, 2007 2:22 AM
> To: jPOS Users
> Subject: Re: ISO 8583, transaction processing, and issuing prepaid cards
>
>
> Ok, let me replay this back to you so I can confirm I understand it:
>
> 1) As a small transaction processor I will generally not talk to the
> bank or network directly. Rather, I will talk to the bank's "gateway
> partner".
>
AAO: Probably correct. Note that there are some banks - like Fifth Third
(Cincinnati) most notably - who are also gateway processors.
> 2) I will generally communicate with the gateway partner in at least
> two formats:
> - OLTP (online transaction processing), aka "auth-level"
> communications happen via ISO 8583
> - Batch processing be done with "authorization files" and "settlement
> files", both of which are proprietary
>
AAO: Almost correct. Where you say "authorization files," I had earlier
mentioned "Acknowledgement Files." Authorization is all done via OLTP.
> 3) In the case of US Bank, the gateway provider is Elan Financial
> Services.
AAO: Correct...although I'll re-emphasize that I'm not putting that out
there as a recommendation, but rather to serve as an example re. the
dynamics of how the players interact. See http://tinyurl.com/2s7qbr In my
experience, the Elan gateway is a good one, but so are FDR North and Fifth
Third.
>
> 4) The holy triumvirate of documents I want are the "auth",
> "settlement", and "telecom" specifications. These will be provided to
> me by the bank's gateway partner, and not the bank (ie, by Elan, and
> not by US Bank). I'm guessing each document covers the following:
> - Auth spec: Defines the authorization file format I'll send to the
> gateway partner
> - Settlement spec: Defines the settlement file format I'll send to the
> gateway partner
> - Telecom spec: Defines the specific variant of ISO 8583 I'll use to
> communicate with the gateway partner
>
Auth spec: No, this defines the auth interface (ISO8583 variety employed,
field specifics, message set, etc.).
Settlement spec: Correct.
Telecom spec: No, this defines the TCP/IP transport layer (you pick or
build a channel manager based upon this information.
> Ok, this is extremely helpful. Thank you. A couple followup
> questions:
>
> a) What exactly does the bank's "gateway partner" do (eg, Elan
> Financial, in the case of US Bank)? Are they, as the name implies, a
> stateless middleman who merely transforms and funnels all external
> messages into a single format for my consumption and processing? Or
> do they actually perform operations upon those transactions based upon
> some database of card/account state that they maintain? I'm guessing
> (hoping) it's the former.
>
AAO: It's the former...although you can engage a gateway to perform
stand-in authorizations for you. I know the Interlinks and STARs (regional
debit networks) offer that service to their clients.
> b) You mention a "gateway spec" above; is this different than the
> triumvirate? Or does the gateway processor ingest the triumvirate and
> instead publish to me a single unified "gateway interface" that I
> implement?
AAO: By gateway spec, I'm referring loosely to the three specs provided to
you by any gateway (auth, settlement, telecom).
See my On-Boarding guide here:
>
> c) By what interface would I typically perform the non-transaction
> operations such as issuing a new card number, loading funds onto the
> card, and canceling the card? (I realize I'll have separate
> interfaces with card manufacturing, personalization, and fulfillment
> bureaus, but for this question I'm specifically referring to the other
> digital operations.) Are these performed through the authorization/
> settlement files, or is this another interface entirely? If so, is it
> directly with the bank, or also through the gateway partner (eg,
> Elan)?
AAO: That is your app. I don't mean to sound flip here. You need to
conceive and build an application to do that. In terms of what you can and
can't do: you own the cards, so you can make the auth decisions you need to
make based upon your business model. For example, we have a client who sets
and maintains a 'minimum balance' on each card type (so they have wiggle
room to assess fees each month). The Available Balance is calculated as
Current Balance less Minimum Balance, so our engine can and will reject a
transaction even in situations where the remaining balance would be > $0.
There are dozens of little nuances like this that make up the framework of
your application.
>
> d) If the transaction processing logic isn't defined by ISO 8583,
> where is it defined? For example, I'm assuming there are rules
> specifying what is or is not allowed by the network (eg, I'm guessing
> it would be forbidden to arbitrarily decline all transactions with an
> odd-valued amount). What is the name of the document that spells this
> out in detail? Should I ask MasterCard, Elan, or US Bank to get it?
>
AAO: Again, this is your app. We spent some significant man-months
developing a solution for one of our clients to do those types of things.
You're looking at Build vs. Buy situation - see something I wrote on that
subject that Alejandro was kind enough to post on the jPOS web site:
http://jpos.org/w/index.php/BuyVersusBuild
> e) If we are responsible for hosting jPOS on our own servers and
> equipment, I expect we will be required to undergo rigorous
> certification by MasterCard. I'm familiar with the logical and
> physical requirements for MasterCard manufacturing and
> personalization; who should I talk with at MasterCard to learn
> physical/logical security requirements for transaction processing, and
> what should I ask them?
>
AAO: You need to get familiar with the PABP (Payment Application Best
Practices) standard. You need to get audited against that. See:
You'll note that that link brings you to a Visa page. Although Visa
promulgated the standard, it's been adopted by the Payment Card Industry
Security Standard Council (PCI SSC). There's a good blog entry here:
http://pcianswers.com/2007/11/07/pci-ssc-adopts-pabp-as-pa-dss/
>
> Finally, from the 30,000 foot view, what are the steps of getting up
> and running with a jPOS installation for an open-loop prepaid card
> program? (For the sake of argument using Elan and US Bank as
> examples.) Please correct the following list:
>
> 1) Obtain BIN sponsorship from US Bank
> 2) Obtain the auth/settlement/telecom specs from Elan Financial (or
> gateway spec?)
> 3) Establish 2+ redundant datacenters with leased TCP/IP lines to 2+
> Elan Financial datacenters
> 4) Install jPOS + miniGL
> 5) Customize to taste
> 6) Integrate with card manufacturing/personalization/fulfillment
> bureau interfaces
> 7) Integrate with ?? interface for card issuing / activation /
> canceling
> 8) Generate nightly (?) authorization and settlement files and send to
> Elan
>
> In this scenario, jPOS would be on the "front line" communicating with
> Elan, both for OLTP authorization traffic as well as batch
> processing / extract generation. miniGL would provide account
> management for the prepaid cards themselves. We would customize these
> with our own custom business logic as necessary, as well as to
> interface with physical card production and fulfillment. Does this
> sound about right?
>
AAO: Sounds about right (good summary). Some comments:
'??' in Point 7 above is also part of your app.
Point 2 is fleshed out in my On-Boarding doc.
On Point 4, jPOS gets you the ISO interface + q2 + TransactionManager.
MiniGL gets you a double-entry accounting backbone, but "customize to taste"
falls a lot short re. what's left after jPOS and miniGL. You're still
building at that point. By comparison, we used jPOS-EE, then built an app
on top of that to get ourselves out of the box.
No auth file on Point 8
David Barrett
going through your links. But a couple quick clarifications:
Regarding (c -- issuing/loading/cancelling), which you answered
"that's your app", my question was based on the (possibly incorrect?)
understanding that the issuing bank maintained a separate cardholder
account for each card number. Thus even though I create new cards and
assign them numbers from my BIN, I still need to tell the issuing bank
to open a new account, to transfer funds from my funding account to
the new account, to eventually close the account, etc. Is this
correct? If so, my question was "By what interface do I instruct the
issuing bank to open/close accounts and transfer funds between
accounts?"
Or, is the issuing bank shielded from the low-level details of my
program, and do they instead treat me as simply having one big bank
account that is the sum of all cardholder accounts? This would
actually be my preference (ie, I'd prefer to simply have one big
account that I allocate internally), but I thought this wasn't the
case.
Regarding (d -- authorization logic), I'm happy to take on the
responsibility for my own state machines; I was specifically curious
what constraints are placed upon my design decisions. I tossed out
the silly example of declining transactions with odd-numbered amounts,
which I assume breaks some MasterCard rule. However, I'm curious what
exact rule that violates, and where those rules are spelled out. Does
this clarify my question? Is there some document I can ask MasterCard
to provide me spelling all the authorization rules/requirements out in
detail?
Thanks again, this has been enormously helpful and educational!
-david
chhil
When creating cards you need to make the banking host know about this because this would mean those would get declined if you went for a authorization and did not do stand in. The host interface may give you access to their card management programs through an online interface or through 8583 card update messages. These take care of sending instantaneous messages on new cards and also allow you to exchange information about hot cards this way..
As for the authorization rules we generally talk to the client what rules they want, usually we do not decline anything and let the host/network approve/decline and our logic comes into play when we are doing standin. This is something from our product/client perspective.
Hope this helps...
-chhil