Case study · Fintech · Credit Infrastructure

I-SCORE first technical PM at Egypt’s national credit bureau.

When a bank in Egypt makes a lending decision, the data they pull comes from one place. I-SCORE — the Egyptian Credit Bureau — holds the credit records that effectively every licensed bank, financial institution, and microfinance provider in the country relies on before extending credit. I joined as its first Technical Product Manager, owning the product and technical relationship between I-SCORE and the external vendor building its applications. This is what that work looked like, told within the limits of what can be shared.

Role
Technical Product Manager
Period
Jan 2021 — Dec 2021
Placement
Via Div Systems consulting contract
Environment
High-security on-premise · Central Bank of Egypt regulated
Scope
4 application versions launched · vendor relationship owned
Links
i-score.com.eg · LinkedIn

What I-SCORE actually is

I-SCORE is the spine of how credit gets extended in Egypt. The institution’s own description is that it holds close to 100% of the credit data on individuals and SMEs from commercial banks, with banks, financial institutions, and microfinance providers across the country subscribing to its services. That makes it less a credit bureau in the international-comparison sense and more the central data layer the country’s lending ecosystem treats as ground truth.

Most people only encounter that infrastructure indirectly — when an application is approved or rejected. From the inside, it’s a regulated, high-security technical environment that runs on-premise, sits inside the Central Bank of Egypt’s regulatory perimeter, and cannot afford the kind of mistakes that smaller systems can absorb.

What I walked into

I joined I-SCORE in January 2021, placed via a Div Systems consulting contract, as I-SCORE’s first Technical Product Manager. There was no internal playbook for the role. The product layer I was being asked to own — between an external vendor on one side and the internal data, network, and security teams on the other — hadn’t been held by a PM before me. The expectation was that I’d hold it anyway, in production, while the system kept serving every bank in the country.

Most of the people I was translating between were senior leaders in their domains, with regional reputations earned over decades. The way through wasn’t to fake fluency. It was to take the work seriously, ask the question the room actually needed asked, and never confuse motion for progress.

What I shipped

Across the year, I led the launch of four application versions across I-SCORE’s product suite — covering credit, investigation, and identification-check workflows used by the financial institutions in I-SCORE’s subscriber network. The work spanned deployment planning, technical assessment, QA, and the operational tail: tracking deployments inside the on-premise servers, raising incidents when an application went down, participating in disaster replication exercises that kept the architecture defensible.

I also evaluated current and future vendors against technical and security requirements. Recommendations from those assessments fed into procurement and infrastructure decisions. The vendor relationship itself — the day-to-day product and technical contact between I-SCORE and the external team building the applications — sat with me.

The translation work

The harder part of the role wasn’t any single application. It was sitting at the intersection of disciplines that don’t naturally agree, and finding the version of every decision that worked for all of them at once. Database teams care about schema integrity and query patterns. Network and infrastructure leads care about throughput, latency, and segmentation. Security cares about who touches what, when, and why it’s auditable. Business stakeholders across the Central Bank ecosystem care about regulatory clarity and what the report on their desk actually says. The financial institutions themselves, when they were in the room for an implementation or a root-cause analysis, cared about what was going to break next and when it would be fixed.

The mistake in that situation is to try to make everyone happy. The work I learned to do was to make the real tradeoffs visible, name the cost of each one, and let the room decide together — with the document in front of us, not behind us.

What this still shapes

Two threads from this year still run through everything I’ve done since.

The first is Skip Pay. The conviction that financial inclusion done right transforms lives is easy to repeat. The conviction that comes from spending a year inside the data layer, watching whose credit history exists and whose doesn’t, is different. That’s where Skip Pay’s mission came from — not a deck, the desk.

The second is how I work in regulated AI environments. When I ran the Trisilco engagement on CIMB’s modern credit-scoring system in Malaysia, what I brought wasn’t theoretical. It was the feel of regulated credit infrastructure — what auditors look for, where the failure modes hide, why a model that performs well on a benchmark can still be wrong in production. That feel doesn’t come from courses. It comes from a year spent inside one of these environments, on the hook for whether things work.

This page is short on purpose. There’s a lot about that year that lives under NDA and stays there. What you see here is what can be said.