I just had a dialogue that was disquieting. I can’t say with whom, but the dialogue was about the impact of real-time on the world of regulation.
This person said to me that their regulator ran a COBOL-based system that could not handle real-time because it was batch based.
Really, I exclaimed. It’s the 21st century; surely it’s time for the regulator to run in real-time?
Apparently maybe not.
Why would a regulator want to run in real-time, they asked?
Plenty of reasons, I replied, with the strongest being the real-time analytics capabilities that such systems can provide.
What you mean, my companion asked.
I was becoming exasperated as this is not the sort of dialogue I anticipated.
In our modern world, everything is moving to the moment of now.
Not the moment of now – 1 or, as we like to call it, D+ or T+ a few days.
Everything is in the moment of now.
Now is the real-time.
Real time does not mean a second ago or a second from now.
Real time is real time.
It’s now.
It is as you read this.
It just went.
So if I take anything from transacting online to making a call on the mobile to sharing a glass of wine over dinner, all of these things take place in real-time and are then burnt into my memory.
That is what we need in our systems, processes and capabilities.
The ability to track the movements of money in real-time, and analyse and understand what those real-time monetary movements mean in real-time.
From a regulatory point of view, this means looking for real-time compliance and any real-time misdemeanours.
If every transaction transacted by any bank were available to the regulator on a real-time basis, could they track real-time insider trading and real-time money laundering? Of course not. But they would be far better equipped to do this than running such analytics in overnight batch updates to a COBOL system.
Take another different, but related conversation.
I was talking with a transaction banker – a payments person if you prefer – about the movement towards real-time payments as offered here by VocaLink and in Poland by KIR. There’s a new service from the BGC in Sweden that offers real-time payment and real-time settlement, and there are others on their way.
As all of these systems move towards real-time, does it not make sense to think that a bank will move to collocate their processing to the real-time centres operated by their clearing houses?
Not really, my colleague said.
Duh? I replied, in my normal articulate manner.
Not really, they repeated and elaborated by saying, colo is for the high frequency trading world where a nanosecond can make the difference between getting an order filled or missing the deal. We don’t live in that world, so colo makes no sense to me.
What about real-time fraud, I felt like screaming but didn’t.
Surely, if we are moving to a real-time world of banking where millions or even billions of dollars of funds can be transacted, cleared and settled in real-time, we will then also move to a real-time world where everything will be connected, integrated and colocated.
This makes sense as everything from the regulatory viewpoint to the banks own fraud analytics engines will be working in real-time and in harmony together, to track, trade, transact, clear and settle everything in real-time from an itunes download of the latest song by Taylor Swift (yeuch!) to the billion dollars of trade in Apple stocks on a daily basis.
This is because it makes absolutely no difference today, from a technology point of view, to support and process a fifty-cent trade to a fifty-billion dollar trade.
Sure the amounts and exposures are different, and hence the security alerts and blocks will be greater for the latter, but the actual processing and process is the same.
Therefore, if you don’t think that a real-time regulatory analysis or real-time fraud analysis will appear very soon on the horizon to go with your real-time clearing and real-time settlement capabilities, then you’re missing a trick.
Get with it folks.
Cobol is not a bar to on-line transactional systems. We were doing this back in 1983 with considerably less CPU horse power than today. However I do take your point that monitoring system should be close to Real Time processing.
Posted by: Oaksys | January 30, 2013 at 11:22 AM
Well, nobody invests in realtime systems because it is cool, because it's the 21st century, or because someone believes it is best practice.
Trading is real-time (and collocated at tremendous cost) because you want to be the first to react. Risk management is going real-time, because you want to see the impact on exposure before you commit to a trade.
Settlement happens after the fact. Sure, getting down the settlement cycle reduces the exposure to settlement risk, but that's not what is driving your reg capital requirements through the roof. If you want build fraud detection into the process (and everybody does so) - feel free - it's just one step in the process, and as it does not need to be real-time, you have time to sort out any potential issues you might detect.
Today, regulators do an investigation based on evidence which is collected in a tedious process. So why waste the tax payer's money?
Would the regulator want to do real-time market surveillance of the OTC markets? Maybe some time, but that has major impact for the whole market infrastructure, not just for one COBOL platform.
So yes, real-time is coming - but you still have to make the case for it in each single instance.
Posted by: Thomas O. | January 30, 2013 at 11:23 AM
Like so often we jump far too fast to an 'either - or' debate. Either real-time or over night. And like so often the full answer is missed. It is both! We need real-time and we need over night, everything at the time appropriate from a busines, regulatory and due diligence perspective.
Posted by: Fritz Thomas Klein | January 30, 2013 at 11:26 AM
And Real-Time requires an instantaneous and fully interoperable underlying multi-purpose Trust Framework which can provide the necessary Privacy, Authenticity, Integrity and Non-repudiability of each transaction. Borderless (like the internet) not nationstate by nationstate...
Posted by: John G Bullard | January 30, 2013 at 01:37 PM
This is an on-going debate with many antiquated IT departments who will argue on many topics that near real time is ‘good enough’.
When the next question is asked then their heads go back in the sand:
So when I get my cash out of the ATM and the ‘Near real time’ checks don’t highlight a problem – then how do they get the cash back.? The same applies to goods at a POS counter.
Fraud checks are often done in near real time – too late the deal has been done.
Please can we get ‘Near Real Time’ out of the vocabulary – before it’s too late !!!!
Posted by: Roger Boak | January 30, 2013 at 05:21 PM
Real Time computing has been around for years in the shape of analogue computers and industrial process control systems, but they rarely include transactional features such as roll-back and complete audit trail. Many of the MSDOS/Windows and UNIX type systems are arguably not Real Time operating systems, but are effectively timesharing.
Real Time systems are not required for compliance and regulatory controls, however such control systems should be very fast systems, perhaps termed "Near Real Time". They are similar but not the same.
Posted by: Oaksys | January 31, 2013 at 09:56 AM