Network Northwest
English
Book a demo

Network Northwest · Chorley, Lancashire

Verification built for licensed gambling, not adapted to it.

Banks verify a customer once. A licensed operator has to prove age before the first stake, check an exclusion register on every login, and show the file years later. That is a different product, and this is it.

See the coverageHow a check runs
  • 5regulated markets, each with its own regime
  • 24 smedian from first frame to verdict
  • 1integration, whatever the market
  • 0data leaving your chosen region

The problem

Generic identity checking stops exactly where gambling compliance starts.

A horizontal verification platform will tell you that a passport is genuine and that the face in front of the camera matches it. Useful, and nowhere near sufficient: nothing in that answer tells you whether the player is on a national exclusion register, whether the deposit pattern has outrun what they can plausibly afford, or whether you can still produce the evidence when a supervisor asks for it two years from now.

Those are not extra features bolted onto identity. They are the obligations that actually carry licence risk, they differ in every market, and they are the reason this platform only serves one industry.

One API. The sources each market requires. An audit file that outlives the account.

One contract. The sources behind it change without you.

One integration

You build once. We change what sits behind it.

Every market needs a different set of sources, and sources go down, get bought, change their terms or stop being the best option.

Absorbing that is the whole reason this layer exists. The test of the promise is boring and specific: when a source is replaced, does anything change in your code? The answer has to be no, or the layer is decoration.

    • Routing decides per check, not per account, because an operator may run several licences
    • A source that is timing out is routed around before it becomes your incident
    • The live response never names which source answered — the evidence bundle does
How routing decides

Coverage

Five markets, one integration

Each row is a separate regime with its own supervisor and its own exclusion source. Filter to the one you are licensed in.

MarketIdentityAgeSelf-exclusionSanctions & PEPSource of fundsMonitoring
United KingdomUKGCsupportedsupportedsupportedGAMSTOPsupportedsupportedsupported
GermanyGGLsupportedsupportedsupportedOASISsupportedsupportedsupported
ItalyADMsupportedsupportedpartialoperator filesupportedsupportedsupported
SpainDGOJsupportedsupportedsupportedRGIAJsupportedsupportedsupported
PortugalSRIJsupportedsupportedpartialoperator filesupportedsupportedsupported
  • ✓Supported
  • !Partial, see the note
  • –Not applicable in this market

Mechanism

What happens between the player tapping Continue and your verdict

Open any step. The latencies are medians measured across production traffic, not best cases.

  1. 01Intake< 50 ms

    You post the player's declared details and the market they are registering in. The market decides everything downstream: which register is authoritative, which documents are acceptable, which thresholds apply.

    Input

    • given_name
    • family_name
    • date_of_birth
    • address
    • market

    Output

    • check_id
    • required_steps[]
  2. 02Document captureuser-paced

    The SDK runs a quality gate on the handset — blur, glare, crop, document detection — before anything is uploaded. A frame that would fail is rejected while the player still has the document in their hand, which turns a failed check into a retake.

    Input

    • front
    • back
    • frame_quality

    Output

    • document_type
    • issuing_country
    • mrz
  3. 03Face match~2 s

    A short liveness sequence, then a match against the portrait on the document. The biometric template is used for the comparison and discarded at the decision; what persists is the score and the verdict.

    Input

    • liveness_video

    Output

    • match_score
    • liveness_passed
  4. 04Register lookup~1 s

    Where the market has a central exclusion register, it is queried here. Where the list is held by the regulator rather than exposed to operators, your own exclusion file is the authority and we check against that instead — see the market page for which is which.

    Input

    • normalised_identity

    Output

    • exclusion_hit
    • register
    • checked_at
  5. 05Screening~1 s

    Sanctions lists, politically exposed persons and adverse media, matched on the normalised identity rather than on the raw strings the player typed.

    Input

    • normalised_identity

    Output

    • sanctions_hit
    • pep_tier
    • media_flags[]
  6. 06Decision< 1 s

    Signals meet your policy. The thresholds are yours, set per market and versioned, so a decision taken last year can still be explained with last year's rules.

    Input

    • signals[]
    • policy_version

    Output

    • verdict
    • reasons[]
    • evidence_bundle_id

Outcomes

Three answers, and no fourth

A verification platform that returns a score leaves the hard part with you. This returns a decision, with the reasons attached.

Pass

Open the account

Every required signal cleared the thresholds in your policy for that market. The evidence bundle is sealed and retrievable for as long as your retention rule says.

Operator receivesverdict: pass

Review

A human looks, with the file already assembled

Something is short of your threshold but not disqualifying — a soft name match, a document near expiry, a deposit pattern that has moved. The case arrives with the signals ranked, not as a raw queue item.

Operator receivesverdict: review + reasons[]

Fail

Do not open the account

An exclusion hit, a sanctions match, or an age that does not clear the market's floor. These are refusals, not scores, and the reason is recorded against the check so you can answer for it later.

Operator receivesverdict: fail + reasons[]

Sealed at the decision, readable in year three.

The file

A verdict you can still explain two years later.

The thing a supervisor actually asks for is not a score. It is the record behind one decision, and whether it still says the same thing it said at the time.

So every check seals a bundle: the signals, their scores, the sources consulted, the policy version that was in force and the timestamps. It is immutable once sealed, which is exactly what makes it worth retrieving.

    • Decisions and extracted fields outlive the images in most configurations
    • The policy version is recorded against the check, so old thresholds still explain old decisions
    • The biometric template is discarded at the decision — the score and the verdict are what persist
What is kept, and for how long

Measured, not promised

  • 24 smedian first frame to verdict
  • 99.9 %monthly availability target for the decision API
  • 5retry attempts before a webhook becomes a pull
  • 2processing regions, chosen once per operator

Latency figures are medians over production traffic. The availability target and what happens when it is missed are both on the availability page.

Start where it matters to you

Tell us the markets and we will tell you what the integration looks like.

A real mailbox, read by the people who built the thing. No form that pretends to have somewhere to go.

ContactRead the API shape first