The story of how, as a young Computer Science graduate at PwC, I found myself helping Kenya’s banks build a real-time payments ecosystem—and challenging the way Kenyans moved money.
There are projects you work on, complete, put on your CV and eventually forget.
And then there are projects that, years later, you look at and think:
I was there when this was being built.
For me, PesaLink is one of those projects.
At the time, I was a young associate at PwC Kenya with a background in Computer Science. I certainly wasn’t walking around thinking I was about to become part of a project that would have a lasting impact on Kenya’s payments landscape.
It started rather ordinarily.
My manager asked me to join a project that the Kenya Bankers Association (KBA) was undertaking. PwC had been brought in to manage the implementation.
The ambition, however, was anything but ordinary.
KBA wanted to implement a new payments ecosystem that would enable real-time transaction processing across banks and deposit-taking institutions in Kenya.
At the centre of it would be a new transaction switch—a gateway through which participating institutions could exchange transactions in real time.
I still remember one of my first meetings.
We were sitting in a hotel meeting room with a group of gentlemen who had travelled from Latvia for a requirements-gathering exercise.
On paper, the initial concept seemed relatively straightforward:
Account-to-account transfers between banks.
But Kenya wasn’t an ordinary payments market.
There was an elephant in the room.
Its name was M-PESA.
The mobile-number question
If we were going to make interbank transfers genuinely useful to ordinary Kenyans, there was an obvious challenge.
People knew each other’s phone numbers.
They didn’t necessarily know each other’s bank account numbers.
So the question became:
How could someone send money to a mobile number and have it arrive in the recipient’s bank account?
Enter the resolution database.
The idea was to create a mechanism that could associate a customer’s mobile number with their bank account. A sender wouldn’t necessarily need to know the recipient’s account details—the system could resolve the mobile number to the appropriate account.
Simple idea.
Much harder implementation.
How many mobile numbers could one customer link? What if a customer had accounts at several banks? Which institution should receive the money? What happened when a customer wanted to change the account associated with their number?
Suddenly, we weren’t just discussing APIs, switches and databases.
We were discussing customer journeys, banking operations, risk, governance and commercial decisions.
And those decisions needed the participation of an entire industry.
Then I was sent to the banks
This is where my role became interesting.
There were 43 bank teams to engage.
And I visited all of them.
My job was to pitch the project, explain how it would work and help each institution understand what it needed to do to participate.
I worked as a technical lead through the ideation and implementation stages with the individual bank teams.
Then came the less glamorous—but absolutely critical—part of delivering a large technology programme:
Follow-up.
Every day, we followed up with institutions.
Where are you with the integration?
What’s blocking you?
Has your team completed this requirement?
What’s the risk to the timeline?
Who needs to make this decision?
What needs to be escalated?
My Computer Science degree helped enormously because I could understand the technology we were discussing.
But I was quickly learning that delivering technology at this scale required something else entirely.
You had to understand people.
“You are all they have sent?”
One particular meeting has stayed with me.
I walked into Standard Chartered to meet their project team. The Head of Projects at the time, Kisheda Mashengu, looked at me and asked:
“You are all they have sent?”
I could understand the reaction.
I was young.
Across the table were experienced bankers and technology professionals, and here I was representing the project and expected to guide them through what their institution needed to do.
There wasn’t much time to worry about it.
I introduced myself.
Opened my materials.
And started explaining the project.
What needed to be built.
How the integration would work.
What needed to be tested.
What their teams needed to prepare.
And how we would get them to go-live.
That experience would repeat itself, in different forms, across Kenya’s banking industry.
And I learned something very early in my career:
Sometimes responsibility arrives before you feel senior enough to carry it.
You carry it anyway.
“We don’t have a budget for this.”
Technology wasn’t always the hardest part.
Sometimes I had to sell the idea itself.
Some institutions would tell us:
“We haven’t budgeted for this project.”
Fair enough.
Banks had existing technology roadmaps, budgets and priorities. Now we were asking them to allocate resources and money to participate in a new industry platform.
My answer was slightly crafty:
“If you don’t join, you miss the opportunity to challenge M-PESA.”
That tended to change the conversation.
Because this wasn’t merely another IT integration.
Kenya’s customers had already experienced the convenience of moving money instantly from a mobile phone.
The banking industry had to respond.
“Won’t this just benefit the big banks?”
The smaller institutions had a different concern.
If we made it incredibly easy to move money between banks, wouldn’t the biggest banks—with their larger customer bases and deeper pockets—benefit the most?
Again, it was a legitimate concern.
My response was equally simple:
Maybe. But if you don’t participate, you also give yourself no opportunity to grow alongside them.
There was another way to look at interoperability.
A smaller institution connected to the same payments infrastructure as Kenya’s largest banks could offer its customers an experience that previously required enormous investment to replicate independently.
Shared infrastructure could become an equaliser.
And what about competition?
There were questions around competition and regulation too.
If the banks were collectively participating in one platform, how would they continue competing independently?
One important part of the model was that institutions still had the ability to determine their own tariffs.
The infrastructure could be shared.
The customer propositions didn’t have to be identical.
Looking back, those conversations taught me something my Computer Science degree never could:
Technology is often the easiest part of transformation.
The difficult part is aligning incentives.
Technology.
Commercial interests.
Regulation.
Operations.
Customer experience.
Risk.
And dozens of organisations that compete fiercely with each other every day.
Then came UAT
Eventually, all the presentations, requirements documents, meetings and follow-ups had to produce something that actually worked.
We entered User Acceptance Testing.
This became one of my biggest responsibilities on the programme.
I arranged and led UAT sessions involving 30 bank teams.
We developed the testing programme, coordinated participation and worked through the scenarios required to demonstrate that transactions could successfully move across institutions.
Think about what that means operationally.
Different banks.
Different technology stacks.
Different teams.
Different internal processes.
Different levels of readiness.
Yet every participant ultimately had to interact successfully with the same ecosystem.
When something failed, somebody had to understand why.
When one institution fell behind, somebody had to follow up.
When risks emerged, they had to be identified and escalated.
When stakeholders needed to make decisions, they needed the right information.
And throughout all of this, we continued refining the customer journey.
Because ultimately the customer didn’t care about the complexity behind the transaction.
They just wanted to send money.
43 banks. 30 UAT teams. One ecosystem.
Gradually, the project began turning into something tangible.
I had gone from bank to bank engaging 43 teams.
Thirty bank teams participated in the UAT sessions I helped coordinate and lead.
The technology was being integrated.
The customer journeys were taking shape.
The operational structures were being established.
Integrated Payment Services Limited (IPSL) was established to operate the platform.
People were recruited.
Teams were inducted.
Banks began going live.
PesaLink stopped being a project.
It became a service.
One of the things I remain particularly proud of is that KBA recognised the improvement in the efficiency of onboarding institutions compared with the earlier Cheque Truncation System project, another major banking-industry initiative undertaken through KBA.
We were getting better at delivering industry-wide infrastructure.
The people behind the project
Projects like this are never built by one person.
I had the privilege of working alongside Samuel, Tonny—now at Oracle—and Faith Mwema, now at SAF Germany.
And at PwC, leaders including Mohammed Karama, Muchemi Wambugu and Alex Muriuki trusted us with responsibilities that, looking back, were enormous opportunities for young professionals.
I remain grateful for that trust.
Because sometimes the most important thing a leader can give a young person isn’t another training course.
It’s responsibility.
And then I joined Safaricom
There’s an irony in how my own career unfolded.
Years later, I would join Safaricom.
Yes—the company behind M-PESA.
The very platform that featured in so many of our conversations about why Kenya’s banking industry needed to make real-time payments easier.
Life has a sense of humour.
But being on both sides has also given me an appreciation for what competition does to an industry.
PesaLink wasn’t important simply because it provided another way to transfer money.
It represented banks responding collectively to a fundamental change in customer expectations.
Kenyans had experienced instant payments.
There was no going backwards.
Today, I look at PesaLink differently
Today, PesaLink processes transactions worth billions of shillings.
Most customers making those transactions will never know about the requirements workshops.
They won’t know about the hotel meeting room.
They won’t know about the spreadsheets tracking bank readiness.
They won’t know about the UAT programmes.
They won’t know about the phone calls chasing integrations.
They shouldn’t have to.
That’s what successful infrastructure looks like.
Eventually, the complexity disappears.
You press Send.
The money arrives.
What PesaLink taught me
When you’re young in your career, titles can be intimidating.
Associate.
Manager.
Director.
Head of Technology.
Head of Projects.
You can walk into a room and assume the people with the biggest titles must have all the answers.
Then somebody looks across the table and asks:
“You are all they have sent?”
And you discover something.
You don’t have to be the most senior person in the room.
You have to understand why you’re in the room.
Know your subject.
Prepare.
Listen.
Think on your feet.
And when you don’t know the answer, know how to find it.
My Computer Science degree gave me the foundation to understand the technology.
PwC taught me how complex programmes get delivered.
The banks taught me that technology has to make commercial and operational sense.
And PesaLink taught me perhaps the biggest lesson of all:
Some of the most consequential opportunities of your career will not announce themselves as consequential opportunities.
Sometimes your manager simply says:
“There’s a project KBA is running. I’d like you to join the team.”
You walk into a hotel meeting room.
You meet a few guys from Latvia.
You open a requirements document.
And you get to work.
Years later, you realise you were watching a piece of your country’s financial infrastructure being born.
And you were fortunate enough to help build it.
I was there.