Our Board members have helped us both strategically and tactically, and have made a big difference. A while back, we talked to them about an initiative that our internal marketing management team came up with: controlling the cost of business transactions. Seemed like an obvious thing to us, but our CIO Advisory Board—to a man—dismissed the idea, and convinced us to drop it. They just didn’t see how it was important.
Generally, we go with the recommendations of our Board members, but in this case, this year we’re going to proceed with the cost-per-transaction concept. The reason is that, two years later, it still makes sense to us. Now our challenge is to make the normally tight-fisted banking CFOs see that reducing the cost of their transactions can make a difference to them and their businesses.
Service charges
And that brings me to an unpopular subject for everyone who has money in the bank—and that means everyone reading this, and most people on the planet—banking service charges. Some of you may be old enough to remember that at one time there were far fewer service charges. Now, of course, we pay service charges on every account, and pretty much every transaction. Think about it: you pay for the privilege of having a bank account (!); you pay to use an ATM; you pay to get monthly statements; you pay to write a check, to order new checks, and for overdraft protection; and you pay to transfer money from one of your accounts to another, and so on—the list never really ends.
The point is that banks understand the idea that if you charge a small amount of money on all or most transactions, it adds up to a tremendous amount of money. It shouldn’t be much of a stretch to see that saving a small amount of money on every transaction could make a big difference to the bottom line as well—every bit as much as any new service charge can. The difference is that saving money on transactions doesn’t adversely affect the bank’s customer base in any way, unlike a new service charge.
Mainframe banking
For the most part, banks—at least the larger banks—use mainframe systems at the heart of their transaction processing infrastructure. They do this for several reasons. Firstly, their transaction processing applications were originally designed to run on mainframe systems: they are optimized to run on the mainframe, on the z/OS mainframe operating system. Secondly, the banks have been developing these applications for years, adding to them, improving them, and updating them as they make changes to their customer product offerings—these applications are under continuous development. And thirdly, the platform is perfect for transaction processing.
The mainframe has grown and improved over the years, right along with banks’ growing and changing needs. It is the most secure platform—pretty important for banking. It has a superior transaction throughput capacity when compared to any other platform because that is exactly what it was designed to do. It also happens to be the most cost-effective platform when running the types of workloads typical of large banks, credit card processors, financial services organizations, etc.
A segue on cost effectiveness: mainframe systems, when configured for five 9s reliability and redundancy, when configured for extremely high transaction throughput, high levels of security, etc., cost less to procure and to run than comparably configured non-mainframe platform networks. Mainframe systems use less power, require far less data center real estate and, most importantly, require far fewer of the costly technical personnel needed to support them. End segue.
Transaction optimization
So how do you optimize transactions that are running on the best transaction processing platform on the planet? Well, without getting too technical, here are just a few ways:
High performance in-memory technology – Faster than caching or database buffering, and faster than in-memory databases, it bypasses database overhead for small amounts of data that are accessed thousands of times more often than 99 percent of system data. This technology has been in use for almost 30 years, and is the best-kept secret in mainframe computing. Faster computing increases transaction processing capacity and reduces the cost per transaction.
Automated resource sharing – Mainframe systems are often divided into logical partitions that help delineate use of mainframe computing resources within an organization. Automated resource sharing allows high-priority processing to borrow resources between logical partitions. This ensures that business-critical processing can run faster without the need for temporary (and costly!) processing capacity increases, and without having high-priority processing held up while lower-priority processing completes in another partition.
Driving down transaction costs
These types of solutions, and many more, can help to bring down the cost of each transaction that a bank runs— every single one—from a customer’s ATM session, to customer debit card transactions, to foreign exchange transactions, to the millions of reconciliation batch transactions that are run at 3AM. The cost per transaction can be driven down further by combining these solutions.
The truth is that every cent—or hundredth of a cent—that can be saved on a transaction passes directly to the bottom line, just as certainly as new income does for any new service charge dreamed up by an up-and-coming banking executive. As banks hoard their cash—as most have been doing since 2008—does it really matter where this cash comes from? And does it make any sense at all to leave some of that cash on the table?
Originally published on LinkedIn Pulse.