From Banking Systems to SecurityNet
From Banking Systems to SecurityNet – A Thirty-Year Journey
I have spent most of my professional life moving data.
When I first started writing COBOL programs at Lloyds Bank in the early 1990s, my job was straightforward. Business users needed information from the bank's systems, so I wrote programs to extract it. It was satisfying work, technically challenging, and it paid well. At the time I thought I was building reports.
Looking back, I realise I was learning something much more important.
I was learning how information moves.
That lesson would eventually lead me to build SecurityNet.
Learning from the banking world
After Lloyds I was approached by a head-hunter and moved to Société Générale in Paris. The bank was planning to migrate to a new version of the Atlas banking system, but the implementation never lived up to expectations. Once again I found myself writing extraction programs against Tandem systems.
By then I had begun asking a simple question.
Why were we repeatedly writing custom software every time someone wanted access to their own data?
Surely there had to be a better way.
That question led to the creation of DAIS Associates. Together with three friends, we designed a system that could extract information directly from Tandem systems without having to write bespoke programs every time.
Each of us contributed different skills. One developed the communications layer, another built the control software, another specialised in extraction routines, while I focused on the overall design and user interface.
What started as an idea became a commercial product.
Banks began adopting it. Lloyds. Rabobank. NatWest. Société Générale itself.
There was no grand marketing strategy.
People bought it because they knew us.
Trust came before sales.
That lesson would stay with me.
An unexpected opportunity
One meeting changed everything.
I travelled to Amsterdam to demonstrate our extraction software to ING Bank.
Ironically, the feature that attracted their attention wasn't the extraction technology itself.
It was a single sentence explaining that users could retrieve data directly into Microsoft Excel.
That was enough to start a conversation.
Although ING didn't buy the software immediately, they later invited me back for a consultancy project mapping how payment data flowed through their European banking network.
At first glance it sounded like a straightforward documentation exercise.
It wasn't.
Following the data
My task was to understand how payment instructions travelled from banks across Eastern Europe into ING's central systems in Amsterdam.
Every country had developed its own way of moving information.
Some systems pushed data.
Others pulled it.
Different applications enriched the data, validated it, transformed it and passed it onwards until eventually it reached the Tandem systems at the heart of the bank.
As I documented every stage, something became increasingly obvious.
The data wasn't standing still.
It was constantly moving.
And every movement created another opportunity for something to go wrong.
Once the mapping exercise was complete, ING asked the obvious next question.
Where are the vulnerable points?
That changed everything.
Instead of simply documenting the movement of data, I was now analysing where information was exposed, where it needed encryption, where it was temporarily stored, and where it might be altered or intercepted.
For the first time, I stopped thinking about databases.
I started thinking about trust.
Security isn't a single product
At the time, there were already many security products available.
Some encrypted stored files.
Others protected communications.
Others specialised in particular operating systems or hardware platforms.
But there wasn't a complete solution that followed the data from beginning to end.
The more I researched, the more I realised that security wasn't a single product.
It was an architecture.
Information needed protecting wherever it travelled.
Not just when it reached its destination.
The beginning of a new idea
When my consultancy ended, I returned home with something more valuable than another contract.
I understood the problem.
I knew the technical requirements.
I knew the budget ING had available.
Most importantly, I understood why existing products didn't quite solve what they were trying to achieve.
So I decided to see if I could build something myself.
I called the project Security Blanket.
At the time it was simply a working title.
I never imagined it would become the starting point for a journey that would occupy the next twenty years of my life.
