Security requirements for Egyptian fintech and e-commerce

The pattern I see repeatedly: a team builds a payment product, everything works, and then somewhere between the first serious customer and the first funding round somebody asks a compliance question. At that point the honest answer is usually that the architecture would need to change, and changing architecture after launch is where the money goes.

Most of what follows is cheap if you design it in and expensive if you retrofit it. That asymmetry is the entire argument for reading this before you build rather than after.

Which regime applies to you

Start here, because teams routinely over- or under-scope themselves.

The row that surprises people is the fourth. If you sell software to a regulated institution, their outsourcing and third-party risk obligations become your contractual obligations: you will be audited by your customer even though no regulator has your name. Budget for it in your sales cycle.

Layer 1: CBE licensing

In June 2025 the Central Bank of Egypt issued licensing and registration rules for payment system operators (PSOs) and payment service providers (PSPs), with a transition period of twelve months for existing players to regularise. The rules introduce licence categories with tiered capital requirements according to which payment services you offer, and, importantly, they reach both entities operating from inside Egypt and foreign entities providing services to Egyptian residents.

Licensed entities fall under CBE supervision covering governance, risk management, cybersecurity, outsourcing and customer protection. That is the part with engineering consequences: once you are inside the perimeter, your architecture, your vendors and your incident process are all supervised.

The practical takeaway for a startup: the cheapest compliance strategy is usually to build on top of a licensed provider so that the regulated money movement happens on their licence, not yours. That is a product architecture decision made in week one, and it is very hard to reverse in month twelve. I go into the specifics for marketplaces in the piece on split payments and deposits.

Layer 2: the Financial Cybersecurity Framework

The CBE's Financial Cybersecurity Framework is the sector's baseline for cybersecurity posture. It is not an exotic local invention; it draws on the NIST Cybersecurity Framework, NIST SP 800-53 Rev. 5, PCI DSS, ISO 27001 and the CIS Controls. If you have built to any of those, most of your evidence transfers.

What this means in practice is that the framework is control-based and evidence-based. An assessor does not ask whether you are secure; they ask you to demonstrate a control exists, is operating, and has been operating. That distinction drives the entire engineering approach:

• Every control needs an artefact. A policy document, a configuration, a log, a ticket, a report. "We do that" is not a control; "here is the quarterly access review with signatures" is.
• Automate the evidence, not just the control. If access reviews are manual, they will be done the week before the audit and never again. If your infrastructure is code and your logs are queryable, evidence generation is a script.
• Governance is in scope. Named owners, an approved policy set, a risk register, board-level reporting. Engineering teams consistently underestimate this half and then scramble.

My advice for teams heading toward supervision: map your controls to ISO 27001 Annex A or the CIS Controls from the start. It gives you a structure that satisfies most of the local framework, is understood by international customers, and does not need to be redone when you expand to the Gulf.

Layer 3: PCI DSS, and how to stay out of scope

This is the layer where an architecture decision made in an afternoon determines whether compliance costs you a questionnaire or a six-figure programme.

The core rule: if cardholder data never touches your systems, your scope is small. The mechanism matters more than the intention.

Rules I hold to regardless of scope, because the failure cost is asymmetric:

• Never store a full card number. Not encrypted, not "temporarily", not in a debug log. Use the gateway's token.
• Never store a CVV. After authorisation it must be gone. This one is absolute and it is the most common finding.
• Scrub payloads before logging. Card data ends up in logs through generic request logging and error reporters more often than through anything deliberate. Redact at the logging layer, not at the call site, so a new endpoint cannot leak by omission.
• Control your checkout page's scripts. A compromised third-party script on a page containing an iframe is a live attack pattern. Know every script on that page, pin them, and use a content security policy.
• Tokenise for recurring billing rather than storing anything yourself. Every gateway supports it and it moves the risk to them.

Layer 4: personal data and localisation

Egypt's Personal Data Protection Law (Law No. 151 of 2018) sets the general regime: a lawful basis for processing, data subject rights, security obligations, breach notification, and restrictions on transferring personal data abroad. Under CBE oversight, financial data carries the strictest treatment in that framework, and localisation expectations for that data have reported compliance deadlines falling in late 2026.

For an engineering team, this turns into four concrete questions you should be able to answer today:

1. Where does our data physically live? Region of every database, every backup, every log aggregator, every analytics tool, every support system. The one people miss is the third-party SaaS: your ticketing system holds customer personal data too.
2. What crosses a border, and on what basis? Every external processor is a transfer. Enumerate them.
3. Can we honour a deletion request? End to end, including backups, logs and downstream systems, with a documented policy for the tension between deletion rights and financial record-keeping obligations, because those genuinely conflict and somebody has to decide.
4. Can we detect and report a breach in time? Detection is the hard half. If your logging cannot tell you what was accessed and by whom, you cannot characterise a breach, and you cannot report accurately.

The architectural implication if localisation applies to you is significant: it constrains cloud region choice, it affects which managed services you can use, and it may rule out tools your team currently depends on. Find out early. This is the single most expensive thing to discover late.

The control set, in build order

Across all four layers the technical requirements converge on the same list. Build it in this order, since each tier is a prerequisite for the next being meaningful.

Tier 1: do this before you have customers

• MFA everywhere, least privilege everywhere. Cloud console, database, admin panel, source control, CI. No shared accounts. Individual identities so audit logs name a human.
• Secrets in a secrets manager. Not in .env files in the repository, not in CI variables copied by hand. Rotate on personnel changes.
• TLS everywhere, encryption at rest with managed keys. Database, object storage, backups. Managed key services make key rotation an evidence artefact rather than a project.
• Network segmentation. Databases in private subnets, no public endpoints, access through a bastion or session manager with logging. This one control kills a large share of real-world breaches.
• Audit logging, append-only. Every authentication, every privileged action, every money movement, every data export. Immutable storage, retention defined, and, critically, logs stored where an attacker with production access cannot rewrite them.

Tier 2: before you are supervised or audited

• Vulnerability management. Dependency scanning in CI, container image scanning, a patching SLA by severity that you actually meet, and a record showing you met it.
• Secure SDLC. Code review required, no direct pushes to main, security review for changes touching auth or money, threat modelling for new services. The OWASP Top Ten is the floor, not the ceiling.
• Backups that have been restored. An untested backup is a belief, not a control. Restore quarterly, time it, and write down the number.
• A written incident response plan. Severity definitions, named on-call owners, escalation path, notification obligations and their clocks, a communications template, and a post-incident review process. Then run a tabletop exercise, because a plan nobody has rehearsed fails on the night.
• Third-party risk register. Every vendor touching your data, what they hold, where they hold it, their security posture, and your exit plan.

Tier 3: the supervised operating rhythm

• Annual penetration test by an independent party, with tracked remediation.
• Quarterly access reviews with sign-off: the control auditors check first, because it is the one that decays fastest.
• Continuous monitoring and alerting on security events, with someone rostered to respond.
• Business continuity and disaster recovery plans with defined RTO and RPO, tested.
• Security awareness training, recorded.
• A risk register that is reviewed, not merely maintained.

A realistic first 90 days

Note what is in weeks 1–2. Teams reliably start at week 5 because controls feel like progress and scoping feels like meetings. Then they build controls for the wrong perimeter. Scope first.

What I actually find

From audits and architecture reviews, the recurring list, in frequency order, not severity order:

1. Card data in application logs. Nobody meant to. Generic request logging plus an error reporter did it.
2. Database reachable from the internet "temporarily" during a migration eighteen months ago.
3. Shared admin credentials, so the audit log records that "admin" did it and no human is attributable.
4. Secrets committed to git. Removed from the current branch, still in history, never rotated.
5. No log retention. The incident happened in March; logs go back thirty days; you cannot answer the regulator's question.
6. Backups never restored. Discovered during the incident, which is the worst possible time to discover it.
7. Every developer has production access, because that is how it was at five people and nobody revisited it at forty.
8. Third-party scripts on the checkout page that nobody can account for.

Every one of these is cheap to prevent and expensive to explain. None of them require a security team to fix; they require someone to own the list.