But digging into that era pulled me somewhere unexpected. Somewhere closer to home.

While NASA was literally weaving memory by hand to reach the moon, the first computers were arriving on the shores of East Africa. The East African Railways was unboxing machines built on that exact same generation of technology. We were stepping into the computer age using the same state of the art that was powering the Space Race.

But what problem was so big it needed a computer to solve it? In East Africa in the 1960s, the answer was sitting on the railway.

The Railway and the Ledger Problem

The East African Railways and Harbours Corporation was formed in 1948, consolidating the Kenya and Uganda Railways and Harbours with the Tanganyika Railway under the East African High Commission. To understand why it existed, you need a short detour into the Treaty of Versailles.

When Germany lost the First World War in 1919, it lost its colonies. German East Africa, which had included what is now Tanzania and Rwanda and Burundi, was carved up and distributed as League of Nations mandates to the surrounding colonial powers. Britain absorbed the mainland territory, renamed it Tanganyika, and found itself administering a railway network that connected awkwardly to the ones it already ran in Kenya and Uganda. The 1948 merger was the administrative tidying up of that inheritance.

By the time computing became relevant to EAR&H, the organization was running rail lines from Mombasa on the Indian Ocean coast through Nairobi and up into Uganda, harbour operations at Kilindini, inland shipping on Lake Victoria, Lake Kyoga, Lake Albert, and stretches of the Nile. It was one of the most complex logistics operations in sub-Saharan Africa, and it employed tens of thousands of people across three territories, each with their own pay grades, overtime rates, allowances, and schedules.

Payroll, in other words, was a nightmare.

The tools available for dealing with that nightmare, before computers arrived, were punched card accounting machines. The lineage of these machines runs directly back to Herman Hollerith, who in 1889 patented a tabulating machine that recorded data as holes punched into cards roughly 18 centimeters long and 8 centimeters wide, with 80 columns and 12 rows of possible punch positions. The holes could represent letters or numbers. The cards could be fed through sorters, collators, and tabulators, which were electromechanical monsters driven by motors of three or four horsepower, their logic implemented entirely through gears, wheels, clutches, and wiring panels that an operator would reconfigure for each new job.

These machines could add and subtract. They could sort. They could print. They could not multiply or divide, not reliably. There was an EAM machine called a multiplier that used vacuum tubes to perform multiplication, but vacuum tubes burned out, and when you had hundreds of them processing thousands of billing cards, the failure rate was a practical problem that defeated the purpose.

Two companies had grown from Hollerith’s original patents. In Britain, the British Tabulating Machine Company, BTM, had been manufacturing its own machines since 1920. In the early 1950s it merged with a rival called Powers-Samas to form International Computers and Tabulators, ICT. In the mid-1950s, ICT East Africa set up its Nairobi operation on the second floor above the Boero car dealership showroom, directly opposite the Donovan Maule Theatre. Boero sold Fiats. ICT sold the future.

The First Real Computer in East Africa

[ ICT 1202 console at EAR&H]

The machine ICT East Africa sold to EAR&H was the ICT 1202, also known as the HEC, for Hollerith Electronic Computer. The name acknowledged the lineage honestly. It was delivered and operational by around 1960, making it the first real computer in East Africa, arguably the first in sub-Saharan Africa outside of South Africa.

It was a valve machine. That means vacuum tubes, thousands of them, each one a glass envelope containing a heated filament and a set of electrodes through which current could be modulated to perform logic operations. Before transistors, this was what computing looked like: hot, fragile, and hungry.

The 1202’s architecture centered on a drum memory, a rotating magnetic cylinder that stored data on its surface and was read by stationary heads as the drum spun past. Input and output was handled by a modified ICT 901 tabulator acting as a peripheral: card reading, printing, and card punching all went through this machine. The console, a desk-like structure with a hood over its panels, had three sections. On the left, electrical meters: mains voltage, DC voltages, current draw, drum RPM. In the center, rows of toggle switches for operator input. On the right, banks of small neon bulbs that reflected the contents of registers. The hood was not decorative. Fluorescent overhead lighting operates at the same flicker frequency as neon indicators, and without the hood you simply could not see what the machine was telling you.

The installation at EAR&H ran into two immediately practical problems that nobody in the UK had anticipated.

The first was heat. Nairobi sits at 1,700 meters above sea level, which moderates the temperature but does not eliminate the need for cooling a room full of hot valves. Air conditioning as a commercial technology did not yet exist in Nairobi in 1960 in any form that could handle this load. The solution was engineering specific to that installation: a custom-fabricated extractor hood was fitted over the CPU cabinets, connected to ducts that ran to the outside wall. The building itself helped. The old wooden structure where the computer was housed sat on short poles about a foot off the ground, like many older Nairobi buildings. Large vents were cut into the floor. Cool outside air came up through the floor vents, through the machine, and was expelled through the roof ducts. The computer breathed Nairobi air.

The second problem was power. Valve filaments are essentially light bulb filaments, and like light bulbs, they draw a substantial surge of current on startup to heat the filament from cold. Multiply that by several thousand valves switching on simultaneously, and the power demand was enormous. So enormous that the local electrical substation serving that neighborhood could not simultaneously support the 1202 starting up and the bakery up the road running its overnight ovens. The bakery baked through the night. The computer had to wait.

The solution was Kuldeep Singh Sunde, a police officer who earned extra income by arriving every morning at five, calling the bakery to confirm the ovens were off, and then spending thirty minutes on the startup sequence. Different units had to be energized in a specific order, spreading the current demand across time rather than concentrating it. Kuldeep would finish the sequence and go on to his regular police duties. The engineers would arrive to find the machine warm and ready.

The primary job was payroll. The 1202 was programmed to compute salaries for thousands of employees with graduated pay scales, different overtime rates, allowances for bicycle use on the job, neatness bonuses for station masters who kept their stations whitewashed and planted with flowers, and the various other categories that a large railway organization accumulates over decades of employment agreements. It was also used experimentally for computing optimum cut-and-fill values in railway route construction, which is genuinely interesting: the problem of how much earth to excavate from a hill versus how much to use in filling a valley when building a level track bed has a non-trivial optimization answer, and the 1202 was being used to find it.

The Snake and the Drum

[IMAGE: 1202 installation]

One night a puff adder came in from the cold.

The building’s elevated construction, which had been an asset for ventilation, was a liability for security. The crawl space beneath it connected to the outside world, and at some point during the night, a puff adder entered through the floor vents and made its way into the CPU cabinet. The machine had been shut down for the night. The extractor fans were off. The drum memory’s sense amplifier section retained warmth longer than the rest of the machine. The snake found it, coiled up, and went to sleep.

That particular morning there had been some trouble in a part of Nairobi with a large Somali population. Kuldeep Singh arrived for his five o’clock shift carrying his service pistol. He went through the routine: called the bakery, confirmed the ovens were off, began the startup sequence. When he opened the cabinet door to energize the drum memory unit, he was looking directly at a puff adder, awake, startled, and rearing.

The snake struck. Kuldeep moved fast enough. His reflexive recoil made him stumble backward. The snake followed him onto the floor. He drew the pistol and fired.

He missed the snake. He did not miss the drum memory of East Africa’s first computer.

The snake went back into the dark. Kuldeep was unharmed. The ICT 1202, pride of East African Railways, was finished. The drum was the irreplaceable heart of the machine. A replacement would have to be manufactured in the UK and shipped out, a process measured in months. It turned out not to matter, because the upgrade to the next generation machine had already been ordered and the replacement was already on a ship.

The disposal of the 1202 was its own small bureaucratic drama. The machine was leased to EAR&H by ICT East Africa, a private commercial entity. When it was first imported, no import duty had been levied because it was going straight into use by a government operation, effectively the government taxing itself. Now that the machine was reverting to a private company, the duty became payable. The duty on several tons of specialized computing hardware, even destroyed hardware, would be substantial. The only alternative was export.

Shipping a pile of wrecked computing machinery back to the UK was not an attractive use of money. But the law only required that it leave East African territory, not that it go anywhere in particular. The 1202 was loaded onto a railway goods wagon, taken to Mombasa, transferred to a barge in Kilindini Harbour, towed by tugboat out beyond the three-mile territorial limit, and in the presence of official witnesses from Customs and Excise, tipped over the side.

East Africa’s first computer rests today under several hundred feet of water in the Indian Ocean, approximately five miles east of Kilindini. It is, objectively, one of the more dramatic exits in the history of computing.

The Second Generation

[ ICT 1500 / RCA 301 ]

The machine that replaced the 1202 was a different kind of computer entirely, not just an upgrade but a generational leap. The ICT 1500 was almost entirely transistorized. Transistors had been invented at Bell Labs in 1947 and by the early 1960s were cheap and reliable enough to replace vacuum tubes in logic circuits. Where the 1202 had thousands of fragile, hot, power-hungry valves, the 1500 had solid-state components that ran cooler, drew less power, and failed far less often.

The name was British but the machine was American. ICT had been racing to complete its own second-generation design in the UK, but transistors had made their valve-era architecture obsolete faster than anticipated. To bridge the gap, they licensed the RCA 301 from Radio Corporation of America and sold it under their own badge. The rebadging was transparent to most customers. What they got was a machine built in the United States to American engineering standards, wearing a British nameplate and supported by ICT’s East African service organization.

The EAR&H installation was configured with 20,000 six-bit characters of magnetic core memory, six tape drives, an Anelex printer capable of 1,000 lines per minute, an RCA card reader running at 1,000 cards per minute, and an ICT card punch at 100 cards per minute. The tape drives transferred data at 10,000 characters per second, roughly eighty times faster than the old 1202’s card-based throughput. The Anelex printer was a drum printer: a cylinder with the characters A through Z and 0 through 9 engraved around its circumference, repeated 136 times for 136 print columns, spinning continuously at 1,000 revolutions per minute while 136 individual hammer solenoids fired at the precise moment the correct character came around in each column position. It was loud, mechanical, and fast.

Programming was done in FAS, the Fifteen Hundred Assembler, or COBOL. There was no operating system in the modern sense. The compiler ran from overlays stored on tape. A minimal COBOL compilation took ninety minutes. A production program, two to three hours. The practical consequence was that engineers quickly learned to save their compiled binaries and debug from there, applying corrections directly to the object program in octal notation rather than modifying source code and recompiling. It was not elegant but it was efficient.

The console was divided into three panels. On the left, error indicator lights. In the center, buttons for selecting what was to be displayed, memory address or status codes. On the right, indicator buttons with backlights that showed the contents of a selected memory word in binary, and which could themselves be pressed to modify the value before writing it back. This meant an operator could reach into a running program’s memory, change a specific word, and continue execution. That kind of direct hardware access is unimaginable in modern computing, but in 1964 it was a standard debugging technique.

Loading a program required a bootstrap sequence so minimal it is almost elegant in its self-referential construction. The operator first keyed a very short sequence of instructions directly into memory from the console. This sequence was just enough to read a single card. That card contained seven instructions and a jump. Those instructions read a second card with more instructions, which read a third, and so on, each stage pulling in slightly more of the loader until the full loading program was in memory and could then load the actual production program from tape. The machine taught itself to read, one card at a time, every morning.

A second ICT 1500 went to East African Power and Light. Their billing problem was exactly the kind of thing that punched card equipment had never handled well: tiered electricity rates, charging customers one price for the first hundred units consumed and a higher price for the next, with different rates again above that. The mathematics was straightforward but the logical branching was beyond what electromechanical tabulators could do. The 1500 handled it easily.

EAP&L only used their machine during day shifts. At night, ICT East Africa ran it as a service bureau, selling compute time to organizations that could not justify their own hardware. Among the night-shift customers were the Post Office Savings Bank, processing savings account records, and the Kenya Tea Development Authority, KTDA, generating payments to smallholder tea farmers across the country. Those farmers, many of them working plots of a hectare or two in the hills of Central Province and the Rift Valley, received their payments partly because a transistorized computer of American manufacture was running their accounts overnight in Nairobi.

The third 1500 went to Dar es Salaam, leased to the East African Customs and Excise department. Its end was the most remarkable of the three. During the upheavals of the 1964 Zanzibar Revolution and the federation that created Tanzania, the machine disappeared from its installation. British intelligence concluded that someone with detailed technical knowledge had systematically dismantled it and arranged for its shipment to China. The People’s Republic, reportedly, received it intact, carefully disassembled it further, studied its engineering, and used it as an educational specimen for their developing computer industry. A machine that had processed the customs ledgers of colonial East Africa became a teaching tool in Mao’s China. You cannot invent this history.

Uganda followed its own path. The Uganda Electricity Board had upgraded from electromechanical punched card equipment to an ICT 1004, a rebadged UNIVAC 1004, which was somewhere between a tabulator and a real computer. It had no magnetic tape storage and was programmed through plug boards like the old EAM machines rather than through a programming language, but it could multiply, divide, and make more complex logical decisions than anything before it. It ran until it broke and no one could be found to fix it. It too disappeared, eventually, into the general entropy of the Idi Amin years.

The Man Who Connects It All

[Fair warning: this next section is pure geek territory. The East Africa history is mostly done. This is me falling down a rabbit hole]

All of this history, the photographs of the machines, the stories of the bakery and the snake and the Indian Ocean, came to light through one man: Jitze Couperus.

Control Data Corporation was the company that made IBM nervous. Built around one obsession: pure speed. The kind of machines that weapons labs and weather services and nuclear physicists lined up for. And the man behind that obsession was Seymour Cray. That is the company whose employee card Jitze Couperus carried.

He was born in Nairobi. His education at the Prince of Wales School, a boarding school of about 600 boys, was cut short by the chaos of Congolese independence in 1960. When Belgium granted independence to the Congo, the country collapsed within days into secessionist violence and inter-tribal warfare. Belgian refugees streamed across borders and the school’s dormitories were commandeered to house them. Couperus was a senior with years in the Combined Cadet Corps, the school’s equivalent of ROTC, and he spoke Dutch, which made him useful for communicating with the Flemish-speaking Belgians. He stayed to help manage the chaos while other boys were sent home.

Once the situation at the school stabilized, his skills were redirected closer to the crisis. He was called up into the Kenya Regiment and seconded to the 4th Battalion King’s African Rifles in Uganda to help manage the growing refugee problem. He served about six months, was demobilized, and came out as a civilian policeman filling administrative gaps in the colonial civil service as the independence transition accelerated.

The colonial government, watching its experienced administrative staff decline to renew contracts and leave for Britain or elsewhere, decided to offer certain people an incentive to stay through the transition. The offer to Couperus was this: stay until independence and the Government would pay for retraining in a new profession. He had already done some part-time work for BTM East Africa dealing with punched card equipment. BTM, by then becoming ICT, agreed to hire him on condition that he first completed a two-year apprenticeship with the British Post Office to learn Computing Machinery.

This is where the story gets strange.

In Britain, the Post Office was not merely the mail. It was also the telephone company, responsible for all research, design, and deployment of telephone, telex, and telegraph infrastructure across the UK. And it had a history in the early development of computers that was still, in the early 1960s, largely classified.

Couperus’s apprenticeship sent him to the Post Office Laboratories at Dollis Hill in northwest London and to the Post Office Training School at Bletchley, a Victorian manor house in a small village north of London that would later become famous as the wartime home of Britain’s codebreakers. His time alternated between periods at those facilities and brief placements with ICT customers around the UK, the classic British sandwich course structure.

His tutor at Bletchley was a man named Tommy Flowers.

Couperus had no idea who that was. Flowers introduced himself as being employed by Standard Telephones and Cables, a manufacturing company based in Harlow with close ties to the Post Office. His prior career was not discussed. It was classified. And it would remain substantially classified for another decade.

What Couperus did not know was that Tommy Flowers had been the engineer who built Colossus.

Colossus was the world’s first programmable electronic computer, built at Bletchley Park during World War II to help break the Lorenz cipher used by the German High Command. It had come about because Flowers, trained as an electronics engineer, had spent the years before the war trying to build an electronic telephone exchange with no moving parts, using vacuum tubes to replicate the logic of electromechanical relays and stepping switches. He had not entirely succeeded, but in the attempt had accumulated a unique body of knowledge about how to build the basic computational building blocks in electronics: flip-flops, counters, Boolean logic gates, clock sequencers. Nobody else in Britain had this specific combination of theoretical understanding and practical experience.

When Turing’s team at Bletchley needed hardware that could process data at electronic speeds, Flowers was the man who could build it. He proposed a machine using 1,800 vacuum tubes, at a time when the most complex electronic device previously built had used about 150. Bletchley management was skeptical. Flowers funded part of the construction himself. His team at Dollis Hill built the first machine in eleven months. Colossus Mark 1 operated in January 1944 at Bletchley Park. Mark 2, with 2,400 tubes, went operational on June 1, 1944, four days before D-Day, and immediately provided intelligence on German defenses that shaped the invasion plan.

Ten Colossus machines were built and used during the war. All were dismantled afterward except two, which were moved to GCHQ and used through the Cold War before being decommissioned in 1959 and 1960. The entire program was classified for decades. Flowers received no public recognition for his achievement during his lifetime. He remained, to his apprentices in the early 1960s, simply a quiet man with an extraordinary depth of knowledge about how computers actually worked.

What Flowers assigned Couperus, as a final practicum for his apprenticeship, was this: take an existing program running on a machine in Cambridge and speed it up by a factor of ten.

They achieved a factor of thirty.

The method was to redesign a core data structure and introduce a new hardware instruction. The program was operating on what amounted to a three-dimensional stack of boolean matrices. The critical operation required counting how many positions in a particular column through that stack had a value of one. In the existing implementation this required a loop: iterate through each sheet, test the bit, increment a counter, repeat. Slow.

Couperus and Flowers redesigned the storage layout so that all the bits at a given X,Y coordinate across the full stack of sheets were packed together into a single word of memory. Then they designed a new instruction that could count the number of set bits in that word in a single operation rather than a loop. The speed improvement came from eliminating the loop entirely for the inner computation.

In CDC parlance, what they had designed was the population count instruction, popcount, which counts the number of set bits in a word. Seymour Cray put it in the CDC 6600. He put it in every machine he ever designed after that. The popcount instruction remains in modern processor architectures today, including the x86 POPCNT instruction available on every desktop and laptop built in the last fifteen years.

Whether Cray arrived at it entirely independently or whether some thread of communication connected his design decisions back to what Flowers and Couperus had built in a workshop at Bletchley, Couperus said he was never certain. What he knew was that when he eventually sat down at a CDC machine and read the instruction set architecture, the instruction was there.

The path from Bletchley to Palo Alto was improbable. Couperus had been working in the Netherlands for ICL, the successor to ICT, and decided he wanted to emigrate to the United States. He applied to every major American computer company: IBM, UNIVAC, Burroughs, Honeywell. Without a bachelor’s degree, let alone a master’s, he could not get through the door for an interview. He applied at the Australian consulate in Rotterdam for emigration paperwork instead.

Within days, a man with a crew cut, white socks, and large wing-tip shoes invited him for coffee at a restaurant near the American Embassy in The Hague. The man identified himself as an embassy attaché. His first question was whether Couperus was the same person who had worked with Tommy Flowers. His second question was why Australia.

Couperus said he wanted to work for a computer company but nobody in America would talk to him. The attaché assured him that would not be a problem and offered to make introductions. A few days later, a phone call came from someone named Seymour Cray (a legend), who offered a job at Control Data Corporation, with visa assistance included. Hardware research in Chippewa Falls, Wisconsin, or software research in Palo Alto, California. Couperus chose Palo Alto. He joined CDC and spent thirty-two years there.

He retired in Silicon Valley, having left Nairobi as a part-time punched card technician and arrived in California as one of the people in Seymour Cray’s organization who understood, at a very deep level, how the machines worked. He understood because he had built a piece of them.

The Ground It All Stands On

This history matters for a reason that goes beyond the technical curiosity of it.

East Africa in the early 1960s was not a passive recipient of technology developed elsewhere and delivered as a finished product. The organizations that used these machines, EAR&H, EAP&L, KTDA, the Post Office Savings Bank, were not test cases or charitable experiments. They were customers with real operational requirements, and the solutions built for them required genuine engineering judgment: a custom cooling hood fabricated specifically for Nairobi’s conditions, a startup sequence coordinated with a bakery’s overnight schedule, a service bureau model that split machine time between a utility company and smallholder tea farmers who needed to be paid.

And one of the engineers who came out of that environment carried knowledge that ended up embedded in the architecture of the machines that defined what supercomputing meant for twenty years.

The EAR&H itself did not outlast the political era that created it. The Arusha Declaration of 1966 split harbours from railways in the name of efficiency. By 1977, the East African Community had dissolved under the weight of the different ideological directions taken by Kenya, Tanzania, and Uganda, and the mutual suspicion between Kenyatta, Nyerere, and Idi Amin had made cooperation impossible. The shared infrastructure was partitioned into three national systems.

The computers outlasted the corporation. The snake outlasted the computer. The instruction that Flowers and Couperus designed in a workshop connected to Bletchley Park outlasted all of them, still running in silicon today in every processor that implements POPCNT.

That is the thread. Nairobi, 1960s.

This city never ceases to amaze me. Every time I think I have mapped its history, something like this surfaces. A thread that runs from a railway payroll straight into the architecture of supercomputers in Silicon Valley. There is more here than we give ourselves credit for.

And as Artemis II carries its crew back to the moon after 54 years, safe travels to the astronauts. Come home safe.

Stay curious.

We use it constantly. We build entire businesses around its APIs. We complain when there’s hiccups.

But honestly, very few of us know how the original system was actually built under the hood. The big story everyone tells is the impact: financial inclusion, the agent networks, Africa’s mobile money revolution. The engineering side? It’s stayed pretty hidden.

I got curious after a chat with my manager she worked in telco back in the early 2010s at Ericsson, and we were talking about how Ericsson was slow to really push a mobile wallet solution while Huawei moved fast and ended up powering the next phase of M-Pesa (after that big 2015 migration from the old German-hosted setup).

What I found digging around online and in old technical write-ups is genuinely fascinating. Five engineers from a small consultancy. A few intense months to ship something usable. Feature phones on networks that dropped calls mid-sentence. And from that they created a system that, in just a few years, was moving roughly 10% of Kenya’s GDP.

The first version feels so alive and so Kenyan: pragmatic, clever shortcuts, decisions made because there simply weren’t enough hands to do it any other way.
Later versions changed a lot of that spirit. Not always for the better, in my opinion. But that’s for later. Let’s talk about the beautiful, scrappy original version.

A Small Consultancy, Intense Pressure, and a Clear Mandate.

In 2005, Vodafone through a DFID-funded initiative commissioned a small UK-based technology consultancy called Sagentia (based in Cambridge) to develop the prototype for what became M-Pesa. The core team consisted of roughly five engineers tasked with delivering a functional system in just a few months.

The constraints were unforgiving: limited manpower, a tight pilot deadline, and the need to create something secure and reliable on low-end devices in emerging markets. Safaricom provided essential local support during the pilot (desk space, integration help, a small on-ground team led by figures like Susie Lonie), but the primary software development the .NET backend, communications layer, and central account management was handled by Sagentia.

This actually reminds me of the original Xbox project at Microsoft. It started with a small group of engineers from the DirectX team repurposing Windows kernel components, DirectX APIs, and PC hardware under intense pressure to ship something viable. They hacked together prototypes by stripping down and adapting existing Microsoft tech they knew intimately shortcuts driven by the need to move fast, prove the concept to leadership, and ultimately deliver a console that bridged PC gaming strengths into a new market.

Same vibe here: small teams under real constraints often achieve the most by building on what they already master rather than inventing everything from scratch.

High-level early M-Pesa stack diagram
( SIM Toolkit app + SMS/USSD arrows pointing to SMSC → in-country Local Integration Servers (LIS) → forwarded to remote core → MSMQ cluster → multiple TranProc workers → SQL Server at the bottom. Highlighted; MS-DTC bridging MSMQ and DB.”)

The Real API Was SMS (and the Network Was the Message Broker)

One of the most interesting aspects of the early system is that it didn’t behave like a modern fintech backend at all.

Today we expect payment systems to expose REST APIs over HTTP.

But the early M-Pesa system used something very different.

SMS was the API layer.

Every financial command sending money, checking balance, withdrawing cash was encoded as an encrypted SMS message.

A simplified request flow looked something like this:

SIM Toolkit App
      ↓
Encrypted SMS
      ↓
Mobile Network SMSC
      ↓
Local Integration Server
      ↓
MSMQ Queue
      ↓
Transaction Processor (TranProc)
      ↓
SQL Server
      ↓
Outgoing Queue
      ↓
SMS Confirmation

From a modern developer’s perspective, the system was essentially treating the telecom network itself as a distributed messaging system.

Instead of HTTP requests, the backend processed financial instructions delivered through SMS packets.

Full transaction request flow diagram

The Little Workers That Moved Kenya’s Money and a Nod to the Future

The encrypted SMS never hit the database directly.

It landed in MSMQ incoming queue, outgoing queue. That decoupling was magic. Network drops? Queues just buffer. Spike in traffic? No problem.

Then the real workhorses kicked in: TranProc (Transaction Processor).

Each TranProc was a simple .NET process that would:

1. Grab a message from the incoming queue

2. Decrypt and decode it

3. Call the relevant stored procedures

4. Decide what response messages to send

5. Push them to the outgoing queue

You could (and did) run many TranProcs side by side. More load? Launch another instance. It was message-driven before anyone called it that all on plain MSMQ.

Reading this again, the parallel TranProcs remind me so much of Cloudflare Durable Objects, which came around 20 years later. Durable Objects are these globally unique, single-threaded instances that combine compute and storage in one tight package each one gets its own persistent state (KV or even SQLite now), processes requests sequentially for strong consistency, and you can spin up effectively infinite ones across the edge.

The TranProcs were doing a primitive version of that idea: independent workers pulling from a shared queue, each handling transactions in isolation but coordinating through the queue and database for consistency. No fancy global routing or edge distribution, but the spirit of “scale by adding more isolated compute units that share nothing except a message bus” feels eerily similar. In 2005 it was a practical hack for a small team; today we have serverless primitives that make it feel elegant. Wild how these patterns keep resurfacing.

MS-DTC, Stored Procedures, and the Honest Trade-offs

With only five people they had to make ruthless choices.

They leaned heavily on MS-DTC (Microsoft Distributed Transaction Coordinator) so one logical transaction could touch both MSMQ and SQL Server and still rollback cleanly if anything failed (especially if the confirmation SMS never made it back).

It was brilliantly simple for correctness… but long-lived distributed transactions are not exactly famous for scaling to infinity. That was fine in 2005. Less fine later.

A huge chunk of business logic lived inside SQL Server stored procedures. Why? Because the database developer had more breathing room than the backend developer. True story.

A transfer was literally:

BEGIN TRANSACTION

UPDATE balances SET balance = balance - @amount WHERE user_id = @sender
UPDATE balances SET balance = balance + @amount WHERE user_id = @receiver
INSERT INTO ledger (...)

COMMIT

Atomic. Fast. Hard to mess up. I still admire the pragmatism.

Database + MS-DTC transaction diagram
( Left side: MSMQ queue + MS-DTC coordinator box. Arrow across to right side: SQL Server with stored proc showing the two UPDATEs and INSERT as atomic steps.”)

The SIM Card as a Tiny Hardware Security Module Pure Brilliance

Here’s the part I find genuinely brilliant: they turned the humble SIM card into what was effectively a pocket-sized hardware security module (HSM).

A real HSM is a dedicated, tamper-resistant physical device built to generate, store, and manage cryptographic keys securely. It performs encryption, decryption, signing, and verification inside a hardened box where keys never leave in plaintext. Banks and payment systems use expensive, rack-mounted HSMs for exactly this reason to keep sensitive crypto operations isolated from the rest of the system. If someone tries to tamper with it, the keys get wiped or the device bricks itself.

In 2005–2007, no one was going to put a full HSM in every Kenyan’s pocket. But the SIM card already had secure crypto capabilities: it could run small Java applets (via SIM Toolkit), store secrets like authentication keys, and perform symmetric encryption and signing without exposing anything to the handset’s OS.

So the M-Pesa team pushed the critical security boundary all the way down:

• When you enter your PIN and build a transaction (send money, check balance), the STK app on the SIM constructs the request.

• It uses your PIN (or derived keys) to encrypt and sign the payload right there on the SIM.

• The encrypted, signed message is sent as SMS.

• Plaintext transaction details never touch the phone’s main OS or memory they stay locked inside the SIM’s secure element.

This is genius for a low-end feature phone world. The SIM acts as a tiny, distributed HSM per user: cheap (already in every phone), tamper-resistant (SIMs are designed to resist cloning and extraction), and perfectly positioned to protect the user’s secrets before anything hits the network.

It’s not a full enterprise HSM with tamper-evident enclosures and FIPS certifications, but for the context billions of low-cost transactions on unreliable networks it was an elegant, context-aware hack that delivered real security where it mattered most: at the endpoint.

That single design choice helped build massive trust fast. People felt safe because their money moves were protected before they even left the phone.

They also made menus downloadable over the air so the same SIM app could serve different roles (customer, agent, assistant) with different views. New features rolled out without SIM swaps. And a unified identity/role model kept everything simple in the backend.

The Trust Rule That Made Millions Believe

If the confirmation SMS failed to arrive within the timeout window, the entire transaction rolled back.

No grey zone. No “maybe it went through”. You either saw the confirmation or your money never left. That one rule turned sceptical first-timers into daily users.

When the Little Project Became National Infrastructure

By 2010: 9 million users (~40% of Kenyan adults), $320 million per month in transfers (~10% of GDP), $7 million monthly revenue for Safaricom.

Still mostly the original architecture.

They later rolled out R9 pulled some logic out of stored procs, reduced MS-DTC usage but the bones stayed the same.

The Germany Era and the 2015 Homecoming

For years the core lived in German data centres. Every transaction crossed oceans and came back. Latency crept up. International cable cuts became scary.

In 2015 they finally migrated everything to Kenya and switched to the Huawei-built second generation platform.

A lot changed after that. More throughput, hundreds of APIs, configurable parameters everywhere, proper hardware security modules (HSMs) in the backend for server-side crypto. It became a polished enterprise system.

Some of the raw, endpoint-focused ingenuity like treating every SIM as a mini-HSM got layered over with more centralized, heavy-duty security. Necessary as scale exploded, but I miss the elegant simplicity of the original approach.

Evolution timeline / migration diagram
(Horizontal timeline 2005 → R9 → 2015 migration.)

What gets me is how human the first version feels. It was built under real Kenyan constraints by people who knew exactly who would use it and how badly the network could behave.

MSMQ as broker, TranProc as the worker army (proto-Durable-Objects style), stored procedures because time was short, SIMs as pocket HSMs for security, one trust rule to rule them all.

They shipped something imperfect and brilliant. And somehow it became the financial rail that carried a country.

If you found this interesting and want to see how the Huawei era changed things (throughput, APIs, centralised security, the whole shift to a more “proper” enterprise platform), let me know in the comments. If there’s enough interest, I’ll dig into the second generation for Part Two.

Until then, stay curious.