Well I’m off to Europe (specifically Poland) for a well deserved vacation

If anyone is in the Krakow region - drop me a line and perhaps we can share a conversation over a Lech or Tyskie in the town square ?

My very first experience with an Atalla was with an old PCI card version of the ATALLA 10000 that was used in an issuer system for CVV and CVV2 verification. Having access to an HSM for development and testing is really a good thing , and is also a requirement is you are building a PIN based debit system, and since not everyone has access to HSM’s in their labs

A friend has recently shared the following link: http://ziggurat29.com/ that includes "BogoAtalla"

This is an Atalla emulator (or simulator).  This software emulation (simulation) of the well-known Atalla Hardware Security Module (HSM) that is used by banks and processors for cryptographic operations, such as verifying/translating PIN blocks, authorizing transactions by verifying CVV/CSC numbers, and performing key exchange procedures, was produced for testing purposes.  This implementation is not of the complete HP Atalla command set, but rather the just portions that I myself needed.  That being said, it is complete enough if you are performing acquiring and/or issuing processing functions, and are using more modern schemes such as Visa PVV and DUKPT, and need to do generation, verification, and translation.

This runs as a listening socket server and handles the native Atalla command set.  I have taken some liberties with the error return values and have not striven for high-fidelity there (i.e., you may get a different error response from native hardware), but definitely should get identical positive responses.  Some features implemented here would normally require purchasing premium commands, but all commands here implemented are available.  Examples are generating PVV values and encrypting/decrypting plaintext PIN values.

I gave it a very quick shot in a test virtual machine:

<00#020035#0101##>

Let’s see — my first error message, invalid character/message

And if you are a real geek- you can use the WRTG version:  BogoAtalla for Linksys — makes a great portable HSM.

I’ll probably play a little more with this in the future.

I received a bill that had an option to pay with a credit card on the back, my favorite part of it is the line that asks for:

SECURITY CODE FROM BACK OF CARD__________________________________________

PCI 3.3.2 - clearly states:

"Do not store the card validation value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions"

Perhaps I’ll write "Call if Security code is required"  um… no — I think I’ll make an e-check — I’m now wondering what they do with these slips after they receive them per PCI 9.6

Don’t forget about receipts, remittences, or other paper items for PCI reviews. How many people would just go ahead and fill this out if they wanted to pay by credit card ?

If you looked at the news on the TV-tube or on a national news website such as www.msnbc.com today you will see that Cedar Rapids, IA is under water. This is a city not far from my home town, and I know there were a few companies that either had to "execute" their disaster recovery (DR) and business continuity (BCP) plans or are putting their businesses on hold.

When I did BCP and DR reviews as an IT Security Consultant mostly for FFIEC Bank Reviews/Assessments, as well when I led this effort at prior companies I was at - these were a few of the items of concern:

Generally the process to create a BCP plan is simple - it is the process of gathering the information, accessing the information, and keeping the information up to date and current (you do have a DR/BCP considerations in new projects and apart of your change management processes don’t you ?) is the painful bit. This shouldn’t be a once a year project that a company assigns an IT person to — it should consist of a committee that meets regularly with input from all departments.

Here are the general steps of the process:

• Perform a business impact analysis - what would happen to the business and its customers during an disruption of business ? - What systems and processes are needed by the business and its departments to function ?
• Perform a risk assessment / threat analysis  — Flood, Fire, Loss of Power, Pandemic Bird Flu, Earthquake, Tornado/Hurricane, Bribery, Computer Attack, Loss of Communication Lines ? — what is the likely hood of this event occurring and what is its impact.
• Develop recovery time objectives - how long can you be down or unavailable ?
• Develop procedures for each department - Safety, Evacuation procedures, command centers, calling lists, off-site inventories, vendor lists, customer contact information, recovery teams, team members and responsibilities.
• Test the plan - Tabletop testing based on mock scenarios, and technical recovery tests of systems are important here.
• wash, rinse and repeat …

With Payment Processing applications the following are topics that you need to think about:

• Batch processing, and transferring of data files. (do you have documented information and equipment and software and configurations to perform this ?)
• Real Time Authorizations considerations
• Communication Links to end-points and providers
• Availability of Backup Hardware
• Data replication strategy
• Backups of systems
• Ability to restore systems
• Data Integrity concerns and potential loss of data
• Security of Payment Card information during a disaster
• HSM, encryption keys and key custodians 
• Reconfiguration of client systems to connect to alternate site
• Are processes and install/setup/configurations documented so some one else other then the "go-to-guy" can perform these steps ? Because he or she is with their family because they lost or are displaced from their home.

I’m sure I can think of more considerations and you can too — but the point was to make you think — another recent event described here: at a hosting center where the hosting center was not allowed to bring up their backup generators and execute their BCP plan because of an order from the Fire Department and safety concerns.

Occasionally there is a need to demo a payment switch to internal parties, customers, business partners, etc.  Depending on the audience of the demo it is really hard to show a payment switch. How do you perform this ? I’ve seen a few methods but none that I particularly like- but this is most likely true with any data processing system- The issue is that it is hard to show something that accepts messages over the network, performs validation and business logic, send them to another endpoint and log the response, back to the caller, while handling exceptions and other considerations.

• You have the toaster, stack or circle diagram that shows the "engine", "components" and all of the modules that can be "plugged" in to support different endpoints, message formats, devices, protocols, etc. — This is actually a pretty good overview from a top-down perspective

• You draw a diagram that shows a device, merchant, acquiring bank, issuing bank, gateways, endpoints, systems in play, operational processes  on a whiteboard, and trace a transaction though its lifecycle typically in a different color of marker.

• You login to a demo system and typically show the "UI" or User Interface of the application and run test transactions using simulators - The thing is the UI really doesn’t do much in many systems in terms of the actual processing of transactions. It is an interface to view transactions, view and set configuration options, and typically view a dashboard or status screen for monitoring purposes — these are all great things, but are only about 10% of the meat of the payment engine.

I’ve found that a combination of these three work out the best, but I get irritated that a payment switch isn’t easily demonstratable. — To me this is similar to Data Center Walk-throughs, I care more about the operational processes and procedures then by being awed by generators, battery backups, security camera, cooling systems, etc.

Payment Systems Podcast - episode #1 -  by: David Bergert & Andy Orrock

In our first podcast we discuss a project that we have been working on to migrate a payment application from legacy hardware to “4 boxes that cost $28,000 worth of hardware.”

 

 Payment Systems Podcast episode #1 [22:38m]: Play Now | Play in Popup | Download

Use Cinch - [http://cinch.blogtalkradio.com]  to record an mp3 and email it or just send a text email to  podcast@paymentsystemsblog.com for any comments or questions.

Music by: Infrared by the Rantings of EVA

Linda Elliott from Glenbrook writes a great summary based on the Federal Reserve Bank of Chicago’s 2008 Payments Conference: read it here: www.glenbrook.com/2008/06/payment-systems.html

Payment Processing Application Performance

One of the frequent concerns about deploying any payment solution is “will it be able to process my transactions in a timely manner?” This is both an easy and hard question to answer. In some instances, a bad application design can lead to poor performance. In others, it is faulty system integration of one or more of the other components causing performance bottlenecks. Generally, there are several major components in the processing of a transaction that can significantly affect throughput and response time performance.

Read the rest of this entry »

Hugh has over 30 years experience in the payment industry including operations, development and marketing roles at leading providers such as Sterling Commerce, FFMC (now FDR) and S2 Systems (now ACI). He has managed operations as well as designed, developed, marketed and sold high volume payment software in the financial and retail industries.

Welcome Hugh and we look forward to your posts!

The current public policy rage about payments is all about congressional motion toward issuing legislation to create a governmental entity to monitor and manage interchange fees. My first thought is yet another governmental watchdog is the absolute last thing we need. My second thought is, something needs to be done to move the majority of the costs of using credit cards to the banks that issue them and the cardholders that use them.  Oh, what a surprise that those who unilaterally decided the retailers would bear the cost burden are now portraying themselves as innocent victims!

The current system puts all the expense of using credit cards on the retailer with no say in what they are or how they are applied. They have a just cause in being up in arms about the situation. Who deemed them the fall guys in this situation? Whatever incremental sales benefit the retailer received in the early days of credit cards when Visa was BankAmericard was always suspect and have long since evaporated.

In the current system, there is no doubt that issuing  or using credit cards are not influenced in the least by  interchange fees.  Issuers change what they want and buyers shoulder none of the costs. There is no pain on the part of the issuer to NOT promote more and more rewards forms and there is no initial purchase cost to the cardholder to use their cards exclusively instead of cash or debit.

It is interesting to see the statements by the card associations where they say fees average 1.6%, when a quick read-through of the public information they provide on interchange fees reflect that is logically impossible. A fee of 1.6% is essentially the lowest fees shown on the rate charts and that rate is only for very basic cards presented for authorization using a very tight set of requirements. For everything else, the fees go up and up, to around 3%.

So, what is the solution? Actually, it is quite simple in concept, albeit a bit more complicated to implement. All that has to be done is change the credit payment system to remove the burden from the retailer and place it where it belongs, on the issuer and the cardholder. Just borrow from the debit model the processing fee pass through amount flows and apply a similar model to credit card transactions.

First, remove any and all restrictions in any agreements to allow the retailer, at its discretion, to pass on some or all the interchange fee to the cardholder or to charge a credit card fee if it wishes. Second, to facilitate this action, the authorizer could be required to supply the interchange fee in the authorization response.  Until that fee pass thru is available the retailer could approximate the fee based on transaction history.

Now, the retailer can decide to tack some or all the interchange costs to a credit transaction just as they do for ATM transactions. If you make a $100 purchase, you could get charged $102.43. If the consumer wants the convenience of credit, then they can pay for it. If not, they can use cash or debit. If the retailer wants a competitive edge; they can pay for some or all the interchange fee.  If the bank wants the consumer to use credit, they can reduce the interchange fee.

With this approach, the retailers no longer have a complaint about interchange fees because the may pass them through to the cardholder. And, the consumer can decide if they want to pay a convenience fee for their credit purchases or not.  The most likely outcome of this approach is consumers will demand lower interchange fees from their card issuer. And the issuers will have a choice of lowering fees or losing customers to debit. So the fight against interchange fees moves to the segment holding all the cards and all the clout.

Best of all, we keep the government, in its infinite wisdom, from destroying up yet another piece of the economy.