It looks like ACI has been at least partly successful with their offer to acquire S1. Partly because the proposed merger between S1 and Fundtech is now history and ACI has averted the rise of an S1-Fundtech combination which would be an even bigger competitor than S1 is on their own right.
So what happens now? By the turn of events it appears that after the ACI offer turned hostile, both ACI and S1 are building up their S1 stock to get control of the company. The S1 board is fiercely fighting against this but, despite initial impressions, it's not going to be easy for S1 to maintain autonomy.
When the S1 stock jumped up a few notches, some sold and some bought. At the end, it appeared that it's not entirely clear if the S1 CEO can rally the shareholders to fight off the attempted ACI takeover. And with the shareholder meeting for the Fundtech merger cancelled, it remains to be seen who has the most votes.
The current situation is not exactly the best S1 hoped for. There is uncertainty amongst both existing and prospect customers, as well as resellers of S1 products. Will the S1 payments platform still be around a year from today? That is the important question here. Although not a betting man, I would be willing to bet that the current situation is hurting S1 financially. Prospect customers, especially those affected by the ACI sunset, would not feel comfortable by selecting S1 now and then find out that they'll be dealing with ACI again after a few months.
With things being what they are, a shadow of doubt is cast upon the S1 future. Even if ACI does nothing at the moment, no one can be sure that they're not just accumulating S1 stock and trying to convince the shareholders to back them up so they can force a change of the board members or reach an agreement with the board behind the scenes.
In that sense ACI has gained an advantage over S1, at least for now. S1 has to clear this mess as quickly as they can, especially during the year of the setting sun. Unless of course, the game ends with ACI managing to acquire their most serious competitor.
Time marches on. Technologies change and systems are upgraded. Every once in a long while, banks have a good hard look at their payment infrastructure and decide that it's time for a change. This may happen every few years or every twenty years, depending on the bank's culture. It's that time of the decade. It's migration time.
An RFI is circulated to several companies. Then an RFP is sent to the select few that seem capable of doing the job of migrating the bank from the, now perceived, old dinosaur to their platform advertised as supporting the latest-and-greatest of technical goodies and being able to drive customer innovation to new unheard-of heights. Committees form to evaluate the responses to the RFP. Vendors drool over the possibility of a new customer, especially if the customer currently uses the arch-enemy's product. Discounts rise to unbelievable heights. The bank negotiates the hell out of the deal.
The bank typically pays attention to the following items:
- Budget. These days, this is one of the most important factors in shaping a decision.
- Vendor capability to execute. Regardless of the value of each product, great attention is being paid at the ability of the vendor to present and execute a good migration plan that minimizes the risks as much as possible.
- Vendor product, customer references, vision and fit. All vendors advertise their product as being the best on the market. But is the product a good fit with the bank? Does the vendor have a product vision? Are there enough positive customer references?
After some time a decision is being made and a migration project begins. Depending on the technological and architectural gap between the system being replaced and the system replacing it, the migration can range from tricky to painful. Some areas are more problematic than others, requiring special handling and attention.
It's a time of change. And a great opportunity for the bank to look hard at some of the existing processes, procedures and infrastructure. I almost always advise against introducing unnecessary changes during a large scale project. Most of the time, changes introduce some level of risk and nobody likes that. However, a radical case such as migrating from a payment system to another offers some opportunities that are simply too great to pass up.
Perhaps the single, most important thing a bank can do at this point is re-evaluate some of the things they do and, most importantly, examine why are they doing them in the way they do. It can be pretty amazing to discover that some things just happen in a certain way because someone was used in doing them that way two systems ago. Or that some manual and/or tedious process can be automated or simply removed because of the architecture of the new system. That's the reason business solution specification cycles tend to focus on the "why" instead of the "how". The question "why is this process in place" is always very important.
Other, more technical, matters can be closely examined during a migration. It is always advisable to try and play by the rules of the new system and not against them. This might necessitate changing a few existing interfaces or alter some existing process to better fit the new system. A good example that comes to mind is the way the host system communicates with the payment system. More often than not, the host uses an application protocol that does not resonate well with the new system designers (especially true for stream protocols with new systems that favor ISO-style protocols). In my experience, re-programming the host to make it understand a modern protocol is always a dreaded exercise. But it's worth it in the long run. Having the new system implement a custom protocol is certainly doable but the repercussions of such a decision will be felt for years - possibly for the duration of the lifetime of the new system. Choosing the modern application-level protocol of choice of the new system that is seamlessly and continuously upgraded to cater for new needs may require an expenditure of a few hundred man-hours of host programmers. But in the years to come no one will have to worry again about protocol translation, mapping and all the related headaches of such maintenance exercises.
Other systems, in production or planned, could also be examined and amended to be as compatible with the new system as possible. As a rule of thumb, new systems tend to offer way more integration options than older systems. It might be a good idea to try and take advantage of this resiliency and avoid ugly hacks that were necessary in order to play with the old system but are now obsolete. Example: channel integration. Older systems usually treated channels very differently according to their capabilities. The result is that newer channels have a hard time communicating with the payment system, making it necessary to resort to weird workarounds. Internet and MOTO channels might use a standard POS interface to send transactions because that was the only way to do it. But if the new system offers a simpler and standardized way to achieve the same result, it's better to bite the bullet now and do the change to use that interface than to suffer from the shortcomings of the old interface forever.
I'm obviously not advocating a complete re-engineering. The norm should be the payment system bending over to cater for the needs of a bank and not backwards. But this rule should not be always be blindly applied to everything. There will be situations where change, especially in existing processes that are not transparent to the end users, could be beneficial to the bank.
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.
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.
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.
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.
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.
