As I wrote earlier in Credit Card Transactions to be Reported to the IRS - in Foreclose Prevention Act of 2008, This bill was signed into law by President Bush today.

The Electronic Transaction Association (ETA) has a good write up on the Merchant Card Information provisions that are part of the American Housing Rescue and Foreclosure Prevention Act of 2008 (HR3221)

"The major outlines of the requirement are clear: Acquirers must report to the IRS the aggregate dollar amounts of credit and debit card transactions for each merchant that has more than $20,000 in transactions and more than 200 transactions per year. Reporting will have to be done by taxpayer identification number (TIN). In certain cases, acquirers may also have to subject merchants to backup withholding."

See the ETA article here for more info and a summary of the final legislation here.

Looks like the burden of this is mostly on Third Party Processors and Acquring Banks who settle transactions directly with the Card Brands, also note that cards types also include ACH, Paypal. and goes into effect at the end of 2010.

Stratus Technologies, famous for fault tolerant computers, the operating system VOS, and its newer ftServers line that can run Red Hat Enterprise Linux or Windows Server 2003 is giving away a book offer on Fault-Tolerance and/or Virtualization for dummies.  Get your copies here.

Stratus has two Virtualization options one for its hardware, another product is a software solution for commodity boxes.  1) VMWare, using the VMWare Infrastructure 3 on ESX,  2) Avance, which uses Citrix’s Xen and other HA components to build a pair of HA Virtual Servers.

I just launched www.paymentsystemsjobs.com a Payment System Job Board.

If you are a blog reader and payment professional - use www.paymentsystemsjobs.com for job opportunities.

If you are an employer or and would like to post a job opportunity for a payment systems professional please see this link:

For the first 20 Job Posts I’m offering a discount code of 100% off,  This is the coupon code to use: PSB20FREE

In the House Amendments to the Senate Amendment to H.R. 3221 – Foreclosure Prevention Act of 2008

See Page 11 and 12 here:

Payment Card and Third Party Network Information Reporting. The proposal requires
information reporting on payment card and third party network transactions. Payment settlement entities, including merchant acquiring banks and third party settlement organizations, or third party payment facilitators acting on their behalf, will be required to report the annual gross amount of reportable transactions to the IRS and to the participating payee. Reportable transactions include any payment card transaction and any third party network transaction. Participating payees include persons who accept a payment card as payment and third party networks who accept payment from a third party settlement organization in settlement of transactions. A payment card means any card issued pursuant to an agreement or arrangement which provides for standards and mechanisms for settling the transactions. Use of an account number or other indicia associated with a payment card will be treated in the same manner as a payment card. A de minimis exception for transactions of $10,000 or less and 200 transactions or less applies to payments by third party settlement organizations. The proposal applies to returns for calendar years beginning after December 31, 2010. Back-up withholding provisions apply to amounts paid after December 31, 2011. This proposal is estimated to raise $9.802 billion over ten years.

This will be very interesting…    

Some commentary here:

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