ACI bid for S1

News of the ACI bid for S1 caught up with my summer vacations pretty quickly. Just a few weeks after the announcement of the S1-Fundtech merger, ACI stepped in and made an attractive bid for S1. According to ACI, its offer represents a more attractive option to S1 shareholders than the S1-Fundtech merge.

Some people would remember that this is not the first time ACI made a bid to acquire a competitor. Back in 2002, if memory serves, ACI acquired S2 which was the maker of Open/2 and ON/2. During those days, S2 held a reasonable size of the market (although much less than ACI). The result of the acquisition was that ACI in effect placed both Open/2 and ON/2 in sunset status. The bid was simply a move to take out a competitor, eliminate the competing products and acquaint ACI with the S2 customer base.

Back then, it wasn't a secret that S2 was not in the best of financial shapes. This is not the case with today's S1, even without considering the financial size of an S1-Fundtech combination.

Perhaps none have more interest in the ACI bid than current and prospect Postilion users. And it is understandable. Users wonder what will the future of the Postilion product be. Would ACI want to capitalize on the platform and continue to develop it? Or would they favor their existing EPS product and just kill Postilion?

It's impossible to tell at this point. The ACI announcement speaks of "complementary products" but that's really not the case. Postilion and EPS have much more in common than not, in terms of functionality offered to end users. Under that light, why would ACI want to keep two pretty different platforms that provide the same offering to their customers? Wasn't one of the reasons to sunset Base24 classic based on the principle of focusing business development on one platform only?

Some might suggest that ACI plan to use part of the technology behind Postilion and incorporate it in their EPS product. If that's so, the logical plan would be to move some of the Postilion tech leads to the EPS team and use their skills there. But in this case, Postilion would be gradually abandoned with no business improvements scheduled and with minimal support for card association updates only. ACI would issue a sunset statement for Postilion in a future date, while figuring out a way to offer a realistic migration plan to EPS to current Postilion users.

Perhaps ACI might even consider a wait-and-see tactic and see how their sales force does with Postilion. Maybe there's a plan to go with Postilion on small and mid-level bids and go with EPS & IBM on large-level bids; not that it makes a lot of sense from a technological point of view.

Considering the above, a buy-to-eliminate plan would seem to make sense. But then again, as a friend of mine pointed out, if that's the case we'd be talking about a very expensive move. And that's true. Spending more than half a billion just to kill off a competitor does seem a bit over the edge and won't get many big fans from the ACI shareholders.

There is still no reaction from S1, other than a statement that the bid will be reviewed by the S1 board. I guess we'll just have to wait for the S1 response to see how this whole affair will play out.

UPDATE: S1 has quickly rejected the ACI bid saying that it was not in the best financial and strategic interest of their shareholders. To translate, S1 is saying that they have complete faith in their own long term business plan. And perhaps rightly so. Postilion has evolved from a regional switch owned by a relatively small company to a global player praised by Gartner, sold and operated worldwide. Considering events of past years, I suspect that the S1 CEO was the driving force behind this decision.

This puts ACI in a bad position. In competitive comparisons, ACI is now going to have a hard time explaining to prospects how their own EPS offering is better than Postilion. Likewise, the S1 sales force will surely make certain that prospects know about this series of events and the failed ACI attempt to buy them.

UPDATE: ACI fights back the S1 board decision and wants to get direct support from S1 shareholders. In my very humble opinion, I very much doubt that the S1 board did not contact the major S1 shareholders before rejecting the ACI proposal. Regardless of what's happening behind the scenes, it's becoming painfully obvious that ACI is not happy with the S1-FundTech deal and will go at any lengths to prevent it.

UPDATE: Well, this is getting more and more exciting. After ACI's attempt to solicit proxies against the S1-FundTech merger,  S1 issued a comprehensive response to shareholders. Soon thereafter, ACI increased the cash part of the bid to acquire S1. I think that ACI is trying to persuade investors not in for the long run to go for the cash. The ACI press releases keep on singing this tune. In these uncertain times, some investors might very well be tempted. The S1 press release recommending to vote for the S1-FundTech merger appears to offer more concrete arguments to shareholders.

The twist in DCC

There are some countries, such as Greece, with intense tourist traffic from all over the world. In cases like these, banks and acquirers that have terminals located at major tourist attractions see a sharp increase in transaction volumes that starts at May, lasts throughout the summer and starts to decline in October. It's no wonder that transaction numbers go through the roof mostly because of acquiring traffic that increases.

If an acquirer or bank find themselves having a lot of well-placed terminals in such a scenario, then an attractive solution that's worth looking at is Dynamic Currency Conversion or DCC at the ATM and the POS. When a cardholder that comes to Greece from outside the Euro zone tries to perform a cash advance at the ATM, the acquirer gives out Euro notes or charges for goods and services in Euros. In order to do that, the acquirer first requests authorization from a card association which in turn routes the transaction to the issuer.

During this process, the card association or the issuer have to do a currency exchange in order to buy Euros. When this happens, a small percentage is charged by whoever is doing the currency exchange and is added to the settlement amount that is debited to the cardholder account. Sometimes this is done by the card issuer, who directly charges the account of their cardholder with this FX charge. Most commonly, this is provided as a service by the card associations to the issuers but when this happens issuers can (and frequently do) request from the card associations an additional percentage to be charged. In essence, the cardholder pays for the FX charge which is pocketed by the card associations and/or the issuers.

The acquirer typically does not see any part of this action. Unless the acquirer performs DCC at the ATM or the POS. When this happens, the cardholder is given a DCC offer by the acquirer at the transaction terminal: get billed in Euros (the transaction currency) or get billed in your own currency at this rate. If the customer selects the DCC offer the acquirer gets to specify the exchange rate, keeps the FX commission and sends the transaction to the card association with the transaction currency, the settlement currency and the exchange rate used.

Why would a cardholder choose DCC? Most of the time, the answer is simply because the cardholder is familiar with his own currency but not the local currency. A Briton understands 100 British pounds but needs to think about what 100 Euros mean. Some cardholders compare the exchange rate of the DCC offer to that given by local exchange rate kiosks and choose the DCC offer because they perceive that it is attractive. Whatever the reason, the business case is huge for the acquirers as they're taking a piece of the pie out of the card associations and the issuers. There are some hidden pitfalls here and there as DCC is a pretty complicated process especially with clearing, settlement and disputes. But still, the business case is very real.

There's a small little catch. It's easy for the acquirer and the merchant to get greedy. Too greedy for their own good. Cardholders forget their typical transactions after a few days but they remember their bad experiences for a very long time. And they let their friends know. That kind of negative viral marketing can go a long way towards hurting the acquirers and the merchants that don't play nice.

How does greed come into play in this business? By understating the simple fact that more DCC uptake means more income. When offering DCC, merchants are supposed to clearly present this as a choice and not as mandatory to the cardholder. Merchants may not do this simply to get the added income; this is particularly true for specific merchants such as hotels. Acquirers, on the other hand, may elect to elevate their exchange rate commissions at specific times and specific places. For example, it's easy to think that for transactions originating from bar or other type of entertainment facilities at 2:00 after midnight the acquirer can get away with doubling their exchange rate - the cardholder probably has other things in mind to notice the inconspicuous exchange rate offered at the terminal.

Eventually, this doesn't go unnoticed. The DCC process is already associated with the word "scam" by some cardholders, simple because they were raped once (or, alas, more than once) in Italy, Spain or Ireland to name some of the European countries where DCC is in widespread use. Eventually, cardholders don't even look at the exchange rate offered and they prefer to deal with the devil they know (Visa, MasterCard and their own bank) than get charged through the nose. Acquirers looking to implement DCC should pace themselves and realize that, if configured wisely and respectfully towards the cardholders, it can provide a respectable source of income.

Lessons learned during a DR implementation

During the last few weeks I've been engaged in the implementation of a disaster recovery solution for a payment system. The task is nearing its completion; usually that's the period where you get the earth move away under your feet due to some unforeseen factor or a detail somehow missed. Thankfully that doesn't appear to be the case in this particular project.

It's always a nice feeling to get such an important and complicated project under your belt. During the course of this project I haven't really picked up any particular technology skills worth mentioning (except being able to break my personal record of the time needed to install the payment system from scratch). However, I gained some experience on practical DR planning and learned a few important lessons. Here are the most significant ones.

• Closely examine dependencies. In the case of a payment system, it's very difficult to have it operate solely on its own. The payment system usually interfaces with a lot of other entities. These can be the bank's host, external card management systems, Visa and MasterCard facilities, help desk system, middleware servers and others. Some of these are more important than others but it should be defined early on what is an acceptable disaster recovery setup. For example, it doesn't make much sense to have disaster recovery planning for the payment system but not the bank's host. These external systems must be a part of the disaster recovery planning as well.
• Make sure that there are well defined, written procedures for switching to the DR site. This appears deceptively trivial, right? Well, it's not as easy as it sounds. It really depends upon the organizational skills of each institution, but it can be a tricky exercise.
• Don't be afraid to break the norm and use the infrastructure available. In my case, keeping the disaster recovery in sync with the production site is officially achieved using replication software. However, the bank already had a SAN in place and that was already replicated to a disaster recovery site. By not following the standard, we managed to leverage what appears to be a vastly superior solution in the DR implementation.
• Test every possible scenario you can think off. By far the easiest DR scenario is one when everything goes smoothly and you can perform an orderly shutdown of all servers, then switch to the DR site. But what about a power outage in mid-transaction? What about a software failure severe enough to render the production site unworkable? Would the plan to switch to DR work under such circumstances? Test it and find out.
• Test exceptional scenarios under load. Everything runs smoothly in the test environment where you have a load of exactly 0.01 transactions per second. How about loading up the test system with 40 TPS and see how a switch to the DR site goes? That's what's going to happen in a real-world scenario.
• Bundle as few infrastructure upgrades as possible in a DR project. It's tempting to say that since we'll test everything, how about also upgrading our database server and also install those 25 patches to the payment system as well? Well, that's a thought and it can save you some time...if everything goes smoothly. But the last thing you want to do is end up chasing down problems due to upgrades while you should be testing the DR plan.

Documentation

I frequent the CodePlex site quite often. As a developer I try to get a glimpse of the efforts of other developers for various reasons. Some of the projects found in CodePlex are a one-year scheme, possibly a junior developer's attempt at fame but without serious motivation. Most of the projects tend to revolve around topics that appeal to the younger developers, especially projects revolving around ASP.Net and MVC, HTML, content management and other related popular technologies.

Occasionally, I find an open source project that stands out from the others. Some time ago I got interested in CommonLibrary.Net. This little project is a library of reusable code but it is different in several ways from other similar endeavors. A very encouraging point is that the project started out in 2009 and the main author is very active, committing regular check-ins and continuously evolving the library and posting releases with new features and fixes. Another feature that grasps the attention of the visitor is the large namespace and the multitude of developer helper classes that were fit into this project. Finally visitors browsing the code can quickly see that it's of unusually high quality, with the main author clearly knowing the tricks of the trade.

There is one sore point, and CommonLibrary.Net is by no means the only project at CodePlex that is problematic in this area. The quality of documentation is poor at best. There are examples of using the library and one project deliverable is a help file generated by the code XML comments. But it's not enough. The examples focus on showing how to use specific namespaces of the library but do not explain the general idea behind them. Browsing the code one can quickly see that there are several problems with the XML comments from which the help file is generated: parameters are not documented, comments are copy-pasted between overloads and are incorrect, class and method comments are frequently vague and a lot of protected or public members remain undocumented.

I think that there are several cases where an open source project can get away with little or no documentation at all. But a developer's library project simply isn't one of them. I would go as far as saying that the documentation may very well be the most important deliverable of such a project. Users of code libraries are themselves developers but that doesn't mean that they want, by default, to see the source code to understand what's being done under the hood. And the notion that a well laid out namespace and use of naming conventions are their own documentation is correct but way overblown if applied to the max at the expense of code comments. True, one can easily gather that ComLib.Scheduling.Scheduler has something to do with scheduling tasks but how are the tasks scheduled exactly? What is a task? What triggers a task? Is there something a task should not do? How can callers know the status of their tasks? Can they stop them, reschedule them, pause them? Can they add a task at dynamically at runtime? At start-up time? How can they gracefully stop all tasks when the program is shutting down?

Fortunately work is being done at CommonLibrary.Net to slowly fix that. It appears it might take a while but it's being done. Documentation for code libraries is indispensable.

Change management

When developers hear of "version control" they tend to think of CVS, SVN, Git or other relevant source code version control systems. The idea behind version control is to have a repository of the work done so far accompanied by the corresponding metadata (who changed a source code file, what was changed, was is the comment of the developer that committed a change, when was the change committed, etc). Version control is such a basic and essential facility that no developer or programming hobbyist who take their work seriously can live without it.

From the perspective of the end-user, the corresponding process to manage the life cycle and operation of a payment system is change management. It has a somewhat different meaning and it refers to the process used to track changes done to the payment system. Change management encompasses the complete range of activities that have to do with the configuration of a payment system. These may include installation of new modules, installation of patches, database or file configuration changes, operating system patches or configuration changes, the method each change is applied and other related information.

The main deliverable of change management is a detailed audit trail of installable modules, configuration changes and people that authorized and performed an installation or change to the payment system. This has the following benefits:

• A change management process ensures proper change authorization.
• It enforces different roles to people requesting a change and those who actually apply the change.
• A change management process can identify change prerequisites or areas affected by a change and it becomes easier to properly manage any related issues.
  
• Change reporting is feasible in a very structured fashion. It is easy to get a snapshot of the latest installed modules, patches or configuration. Likewise, it's also easy to find out the path of installs and changes that resulted in the current system. And it's also trivial to attribute changes to the business entity or person that authorized them. 
• Once in place, a properly used change management system forces you to formally evaluate each change and assess the related implications. Likewise, it ensures that a change is applied by the authorized people in the correct manner. In short, it forces you to do things the right way.

It appears that for some organizations change management is a difficult to grasp notion, despite its easily defined purpose. After all, what's it good for? All organizations have some kind of process that needs to be followed in order to authorize and make changes to a payment system, so what would change management add to this process? 

Well, sooner or later (most probably sooner) one of the following questions will pop up:

• "I want to create a new QA system, what do I need to install and what do I need to configure?"
• "Who authorized taking that patch live?"
• "I want to create an image of the production server for DR purposes. What's installed in production?"
• "Why did we make that change in the database?"
• "How is the system configuration different to the default configuration?"
• "What are the prerequisites before installing this patch in production?"

Without change management, answering each of the above is a time consuming and error-prone task. Change management is therefore very important. It doesn't matter how is it implemented. An organization may elect to create a home-grown change management system, purchase a license for an existing system or go out to a web-based or SaaS-based offering. The important thing is to have the process available and functioning.

Tokenization

For several reasons, the acquirers and banks in the part of the world that I live in have not seriously gone after the web merchants to make them become PCI compliant. I guess that PCI is one of those topics that everyone hates. I believe that for merchants in particular, the subject must really be viewed as a major nuisance.

The word is out, though, that Visa is getting stricter and that there's going to be a fury of activity. Well, it was about time. I'm not a supporter of PCI just for the sake of PCI. But if you think about it, Visa is doing the merchants and the acquirers a favor. Security holes and procedural gaps that could potentially hurt the merchant and the acquirer will be assessed and addressed and that's a good thing. A security breach can be serious enough to close you down. Even if you put monetary losses aside, a breach can generate enough negative publicity to put you out of business.

One way to minimize the scope of PCI is to introduce tokenization. Web merchants that use this technology can get to a point where no sensitive data ever gets into their systems, regardless of what those systems are. Only a card token and possibly a transaction token are stored. This information, if stolen or intercepted, is useless to a data thief and cannot be used to send fraudulent transactions from some other part of the world.

There obviously need to be changes in the authorization flow if tokenization is to be introduced. For the acquirer the exercise is not exactly straightforward. Tokenization is not the typical service that acquirers provide to their merchants, at least not at this point in time. For banks that provide acquiring services to web merchants (and hence have smaller numbers of e-commerce transactions), the economics of the business case are even trickier. This is the reason why there are service providers with offerings that are centered mostly around tokenization and data security.

As payment systems continue to evolve, they will doubtlessly include tokenization as part of the standard transaction flow and the window of opportunity for tokenization service providers will close. Securing the authorization process with card and transaction token will be the first step. Handling recurring payments is somewhat trickier and could be a batch-based process but eventually payment systems will provide a solution for that business need as part of their standard out-of-the-box packaging as well.

Ownership continued

Some time after blogging about "Ownership" it so happened that I got into a meeting with a company that provides payment consulting services. The people of that consultancy company seemed nice and they certainly have been around the block a few times. After discussing a migration project, I was left with the impression that they knew what they were talking about.

As the conversation unfolded, we started broaching the topic of testing and certification. I quickly discovered that the consultants had a very different view of how testing and certification should be handled. I am of the opinion that when an end-user (a bank) wants to in-source their payment system, they should take ownership of all testing and certification activities and immerse themselves in these tasks.

To my initial surprise, I discovered that the consultants favored the extreme opposite approach. They pretty much wanted to come up with the test cases, execute the tests and be in charge of certification cycles. In short, they felt that it is preferable to them to get all over these tasks themselves than help the end-user do them.

"How can the end-user ever get off the ground if they do not own these processes?", I thought to myself. "How can the end-user even operate their own payment system and innovate with it if they can't even go through a test cycle themselves?".I presented these concerns to them. Their response was along the lines "We can provide this service to the end-user".

Some times I'm pretty slow but at this point I grasped the obvious difference between us. The consultants are trained to act on behalf of the end-user. They are hired by the end-user and most of the time adopt the viewpoint of the end-user. When they are successful in a project, they think and act as the end-user and in essence they are the end-user. On the other end of the spectrum lies the vendor that provides the payment system software - the vendor would be very comfortable just selling a license. I happen to sit comfortably in the middle. I work with payment system vendors and, when I'm successful, I help the end-users to integrate the payment system in their organization.

In the end, the consultants virtually re-validated my opinion: for an in-sourced payment system, the end-user must step up and take ownership of the system. Whether this is achieved by the end-user's own resources or by getting hired guns to do the job is a different matter. I'm not by default against getting consultants to run an operation and take on all the things that an end-user might find distasteful. Sometimes the conditions and the economics may be right to do just that, perhaps for a large retailer, a specialized processor or a global bank. But in the long run it just doesn't make sense for the average case. If continuous integration, patching, testing and certification activities appear to be more than an end-user can bear, there's a perfect alternative which is out-sourcing.