Institutional onboarding

When I came on board, only four institutions were live on the network. Nobody trusted it yet.

Banks run on systems they have used for years. I was asking them to join a blockchain network, a technology that was new, cutting edge and something most of them had never worked with, and to trust it with real transactions.

So the job was never only to onboard a bank. It was to get an institution to trust something unfamiliar, and then take it live.

The first ones were slow. In my experience a bank typically took two to three years to onboard, and I have seen five. The first fintechs took eight to ten months, about a year.

Very little of that time was technology. Most of it was approvals. Change management came with a long list of requirements, and that was when compliance and information security would show up, usually late. I kept asking myself where they had been all along.

At the start I was always working out how things moved inside each bank, who to ask and what came next. Slowly the flow became clear. Every bank had its own way of working and a few people who called the shots.

So often it came down to the right person. I would be stuck on something for days, then speak to someone who explained what was actually holding it up, and I would find I had been chasing the wrong thing. They would say, "I'll speak to them internally," and within minutes or hours it was sorted. Days of struggle, ten minutes of someone else's time.

No two clients work the same way. With some, the senior people stay out of the day-to-day and the junior team moves things. With others, nobody below moves until their boss says so, so the relationship that matters is upstairs. Some are fast. Some are traditional and do everything by the book.

For the by-the-book clients I learned to find out which book they follow, so I can see what comes next and not get blindsided. Fighting it only costs weeks, because you end up doing it their way anyway. So I follow their process and speed things up inside it, running in parallel anything that can run in parallel.

Some banks did not believe the numbers. We told them the network had a 99.5% transaction success rate and was fast, because the switching was decentralised. One bank went through the whole integration with that doubt in mind.

Then came their pilot. A card transaction left their system, went through the switch, reached the other bank, passed its front-end processor and core banking system, had the customer's account checked and debited, and came back with a response, all in under a second. Card transactions are known to take a few seconds. This felt like a fund transfer.

They were so pleased that they later told us, of all the processors they connect to, we ranked first for speed and reliability. Clients talk to each other. "What do you think about the network?" Good testimonials travelled, and it stopped being a proof of concept.

Around the fourth or fifth project I noticed that bank projects are similar and different at the same time. I learned where to draw the similarities and use them, and to spot the differences so each project was treated as its own case.

Then we wrote things down. A document that had worked, like a change-management submission, went into a shared store so the next bank got it ready. Every fix went into a register, so a fix one client needed became a standard step for the next, deployed before they found the problem. One client's issue became the next client's feature. The team always knew where to look: on this project you will likely need this, the document is here, a sample UAT test script is here.

Before a project starts, I diagnose it. Who has authority? Is the timeline real? What will take longest? What kind of client and project manager am I dealing with? Compliance and information security come in early, because their reviews take time.

The best proof was a fintech that went live one month after kick-off. The first fintechs had taken about a year.

The client was highly motivated, and I could use everything we had learned. Pilot testing needs test cards from different issuing banks, and we had seen that many clients do not have them, so time was lost sourcing cards. Now we keep a stock of test cards for every issuer on the network and send them out. We worked around the clock, sometimes at 2am, and in about two weeks they were ready for user acceptance testing.

For the pilot, I took the cards to their office myself, with their project manager, and walked them through the testing in person. A pilot that normally takes a week or two was done in two days. They were ready to go live straight away.

At its largest my team had about 20 project managers, and at our busiest we were running about 45 projects at the same time. A method only counts if the team uses it.

At first that took steady reinforcement. People follow a method once they have tested one of your approaches and seen it work. Every new person gets an onboarding into how we deliver: the industry, what to watch for, our philosophy, and where our documents live. In our daily check-ins I can often say, "this is likely the issue, and this is likely the fix." Teach them the philosophy, get them to trust you, and the rest sorts itself out.

It got easier each time, and easiest of all with an existing client adding a new product, because the relationships are warm and the processes are known. That is how ZonePay went from idea to live in under three months. Read the ZonePay case study. Even a brand-new client is never completely new. The names change and the shape stays the same.

Today more than 30 banks and fintechs are live on the network, up from four. Many of them were onboarded quietly, without the wider organisation knowing how it was going. They just heard that another client was live. That is how I know it works.

If I could tell a project manager at a bank joining a network like this one thing, it would be this. Learn the processes, know what applies to which institution, build the relationships, and reapply the lessons.