Why now

The flaw that blocks your CBN approval is cheaper to fix before launch than after.

A product can look complete in internal demos and still fail at the seams: between your KYC flow and your session logic, between your payment API and your webhook handler, between your admin dashboard and your customer data. Those are the boundaries attackers probe first. An independent review gives your team a prioritised decision before real transactions raise the cost of every mistake, and before a CBN examiner or enterprise partner asks to see your security evidence.

The outcome

Three things your team needs before go-live.

A clear go/no-go decision before customers arrive

Know exactly which issues block a safe launch, which can follow in week two, and which are acceptable risk. A prioritised call your team can act on.

A report that survives the CBN and investor conversation

The management summary is written for non-engineers. The technical detail is written for your developers. One report serves both rooms.

Retest status after your team fixes the findings

We re-run the attack scenarios on your fixes and mark each one: Fixed, Partially Fixed, or Still Open. If something did not hold, you find out from us before it ships.

What we cover

Every critical surface your launch depends on.

Signup, KYC and account recovery

Every path that ties identity to access: OTP handling, BVN checks, document upload, password reset, device binding and session creation. A flaw here is account takeover before the product is a week old.

Transfers, payments and transaction logic

Funding, withdrawals, limits, fee calculation, reversals, state changes and payment callbacks. The logic that decides whether money moves correctly, and whether it can be made to move incorrectly.

APIs, authorisation and tenant isolation

Object access, user-to-user boundaries, partner tokens, webhook signatures, rate limits and the server-side enforcement behind every API your product exposes.

Mobile app, web client and admin surfaces

Client-side storage, deep links, sensitive screens, internal dashboards and support tool access. The paths most teams leave for post-launch become the paths attackers use on day one.

A clear engagement

Built around your launch date, not around our calendar.

  1. 01

    Show us the product

    Share the launch date, product surfaces and the flows carrying the most risk. We turn that into a written scope.

  2. 02

    We review it hands-on

    Work stays focused on the agreed applications, APIs, mobile clients, admin paths and infrastructure.

  3. 03

    Your team gets a fix plan

    Every confirmed finding includes evidence, impact, priority and practical remediation notes.

  4. 04

    We retest the fixes

    Once fixes are ready, we verify them and update the status so you can show what changed.

Straight answers

The questions that usually delay the decision.

"We are still changing the product."

Freeze the critical flows (payments, authentication, admin access) for the review window. You can keep building the rest. We focus on the version that will handle real money and real identity from launch day.

"Our engineering team already tests everything."

They should. But internal teams test for correctness, not for what an attacker does at the boundary between two systems. An independent reviewer challenges assumptions your team built into the product and cannot see.

"We can't afford to delay launch."

The review is scoped around your date, not ours. Critical findings are surfaced in the first days so your team can act before the deadline. If a blocking issue shows up late, you find out from us, not from a customer.

"What will the scope include?"

The written scope names each application, API, role, integration, environment and exclusion. It also states the schedule, access, test limits, deliverables and responsibilities. You can review the full plan before work starts.

"How do we get a price?"

Send the product surfaces, user roles, critical flows, integrations and launch date. We use that scope to give you a fixed quote before work starts. You do not need to book a call to receive the first scope.

"We cannot expose customer data."

We start in staging or pre-production. Access is defined in writing before credentials are shared: what we can reach, what is off limits, and how data is handled throughout the engagement.

See the work first

Know what your team will receive before you book.

Review the evidence format, ownership fields and completion status before a scope call.

Before you book

Frequently asked questions

How close to launch should we start?

Book when your critical flows (payments, auth, KYC) are stable enough to test and your developers still have time to fix a significant finding. If the date is under four weeks away, tell us in the first message and we will tell you honestly what is achievable.

Do we need every feature finished first?

No. The review focuses on the flows carrying money, identity, customer data and privileged access. If a feature is incomplete or behind a flag, it can be excluded from scope.

What access will you need from us?

Test accounts for the roles in scope, application builds or staging URLs, API documentation, a brief architecture overview, and one contact for urgent findings. We agree all of this in writing before work starts.

Can this report support a CBN or NDPC review?

The report records scope, methodology, findings, severity, impact, remediation and retest status. Your regulator or auditor decides how that technical evidence fits the full licensing or compliance review.

Is retesting included?

Yes. One retest is included after your team implements fixes. We re-run the attack scenarios and mark each finding Fixed, Partially Fixed, or Still Open. The final report shows the actual state of the product when it launches, not the state it was in during testing.

Start here

Your launch date is the starting point. Tell us what you're launching.

Send your product surfaces, the flows carrying the most risk and your go-live target. We will return a written scope, timeline and next step, usually within one business day.

Scope our pre-launch review

Send your product type and target launch date. We will reply within one business day.