Skip to content

Myaza Trust joins NVIDIA Inception

Matching a face to one document is a contained problem. Searching it against every identity a business has verified is not. Why our fraud work is becoming a compute problem, and why Myaza Trust has joined NVIDIA Inception.

Charles Archibong

, Co-founder

· 5 min read

Myaza Trust joins NVIDIA Inception, beside a graph of identity signals feeding a risk system that decides trust, review or decline.

Checking that a selfie matches the photo on an ID is a contained problem. One face, one document, one comparison, and an answer in well under a second.

Checking whether that same face has already been through your onboarding under another name is a different problem. The new face has to be compared with every identity the business has ever verified, and that set only grows. A small lender runs this against a few thousand people. A large one runs it against millions, on every sign-up.

More of our work at Myaza Trust now looks like the second problem. That is a large part of why we have joined NVIDIA Inception, NVIDIA's programme for startups building with AI and accelerated computing. It involves no investment and no equity. What it gives us is closer access to the tools we need as these workloads move to GPUs.

A genuine document can still open a fraudulent account

An identity check can pass on every count and still let fraud through.

A real national ID number, confirmed against the government database, with someone else's face in front of the camera. The face match catches that one.

The same person opening three accounts with three real IDs is harder. Each check passes on its own, and only a search across faces connects them. So every verified face in Myaza Trust is searched against that organisation's existing customers. A hit goes to a reviewer. We never treat it as proof that two records are one person, because across enough faces, some false matches are certain.

Or twenty applicants at one address. That alone proves nothing: a family compound and a fraud farm both put many people on one pin. What separates them is whether they also share phones, faces, or the same IP address on the same day, so that is what we show a reviewer.

Even the parts that look solved are not. Passports carry check digits so a machine can tell when it has misread the number. We found a passport number our scanner had misread in two places, where the two errors happened to cancel out, so the check digit still passed. Look-alike letters and digits are exactly where text recognition fails. So the scanner now refuses any reading with more than one plausible version, and hands the document to a second reader.

Some signals are worth less than they look. On Nigerian mobile networks, an IP address places a subscriber in whatever city their carrier's gateway is in. We used to show that city. We removed it and now report the country only, because a precise-looking wrong answer does more damage than no answer.

The cost is in the search, not the check

Our face models run on our own servers, so a selfie is never sent to a third party to be compared. For a product that handles biometric data, that was the right call, and it means the compute is ours to solve.

Today those models run on CPUs. To fit them into the memory we had, we quantised the face model to 8-bit integers. Each embedding became about two and a half times slower, and in our tests not a single verdict changed. For one match that trade is invisible. Nobody notices a quarter of a second.

Search is where it shows. Our face search compares a new face with every stored face in the organisation, one by one. That is exact, and it was the right place to start. But its cost grows with every customer our customers verify. The fix is well understood: an index built for nearest-neighbour search, and inference on hardware designed for it.

The same goes for what we are building next. We are working on detecting documents that were edited or generated, not only ones that fail to read. We also want risk models trained on real reviewer decisions, not weights we set by hand. Both are heavier to run than anything we have today.

Our face models already run in ONNX, an open model format. NVIDIA's inference tools, such as TensorRT, accept it, so moving to GPUs is an engineering step rather than a rewrite. Inception gives us NVIDIA's developer tools and technical training, preferred pricing on some of its hardware and software, and cloud credit offers while we make that move.

Better hardware does not make a model trustworthy, though. In August we tested three commercially licensed age-estimation models against verified dates of birth from our own checks. All three overestimated the youngest person's age by twelve years or more. We shipped none of them. Compute makes a good model usable. It does nothing for a bad one.

Evidence is not trust

Identity verification asks whether the identity evidence is valid. Risk intelligence asks whether the account should be trusted.

The first question has an answer at a point in time. The second is never settled. The customer who verified cleanly in March logs in from a new phone in another country in June, and pays someone the account has never paid before.

So the useful unit is not the check. It is the record the check starts. In Myaza Trust a verification creates an identity. What we learn afterwards attaches to it: devices, contact details that were actually proved, addresses, faces seen elsewhere, screening results, transactions. A workflow acts on the combination. It can ask for a fresh selfie, open a case or send the account to review.

Adding signals is the easy part. An analyst still has to be able to read the result. We learned that on our own risk score. It was computed correctly, but the three factors shown next to it did not add up to the number, so nobody could check it. We rebuilt it so every score is a list of contributions that sum exactly to the score. In compliance work, a score nobody can explain is a score nobody can defend.

That principle also limits what we let models do. A model should rank, route and summarise. Who gets refused should be decided by a person, or by a policy the customer can read. Every reviewer decision is kept as a labelled outcome, and that record is what the next model learns from.

What we are building

Identity infrastructure is not going to become a better pass or fail. It will be systems that understand how people, devices, accounts, documents and money relate to each other, and help a business decide what to trust.

That is what we are building.

Building identity, fraud or risk infrastructure? Explore Myaza Trust

Sources

Filed underProduct UpdatesIdentity VerificationRisk & Compliance

Charles Archibong

About the author

Charles Archibong

Co-founder

Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.

  • Headline "One person behind many accounts" beside an illustration of a network of connected ownership nodes, on a warm cream gradient.

    Risk & Compliance

    Finding the same person behind many accounts

    Rank shared artefacts by what they prove. A repeated verified ID number means the same person. A repeated face is strong evidence for review. A shared device, phone or address is common in families, so treat it as corroboration and count distinct people before acting.

  • Headline "Don't trust the phone's verdict" beside an illustration of a shield with a check mark, on a soft lavender gradient.

    Identity Verification

    Why a liveness result from the phone is not enough

    A liveness result produced on the phone is a claim made by a device the attacker may control. Treat it as input, keep the recorded evidence, and re-check that evidence on the server before the result counts.

Build your product.We'll handle the rest.

Identity and compliance, end to end, built to global standards, priced for founders.

Myaza Trust joins NVIDIA Inception · Myaza Trust