KYC Match: what the API actually verifies

KYC Match: what the API actually verifies

CAMARA KYC Match is one of the cleanest APIs in the network-API catalogue, and one of the most frequently misused. The misuse follows a consistent pattern: a relying party treats a KYC Match "yes" as identity verification and skips other identity checks. The API never claimed to provide identity verification. It claimed to match a claimed name and birth date against the operator's provisioning record, nothing more. The gap between what the API says and what some integrators want it to say is where the misuse lives.

This post walks through what KYC Match actually verifies, what the regulatory frameworks around it require, where it materially helps, and where using it as a substitute for identity verification produces design failures.

What the API does, mechanically

A KYC Match call takes a phone number and a set of personal attributes the relying party wishes to verify, most commonly given name, family name, and date of birth, optionally extended with address fields in jurisdictions that permit it. The API returns a match or no-match response per attribute, with some implementations returning a confidence level rather than a binary.

The operator-side resolution is straightforward. The operator holds a subscriber record for the MSISDN, populated at SIM issuance with whatever documentation the local regulator demands (national ID, passport, residency permit, utility bill, employer reference, depending on the jurisdiction). The KYC Match endpoint compares the caller's claimed attributes against this record and reports whether they agree.

The claim is narrow: the subscriber record contains the claimed attributes. It is not a claim that the attributes themselves are truthful, that the SIM is in the hands of the claimed person right now, or that the person presenting the attributes to the relying party is the subscriber the operator registered. The weakest link is often the operator's own KYC process at issuance, which in some jurisdictions and some retail channels is uneven. The legal literature on wireless-provider fraud liability and the regulatory-compliance gap analyses on eIDAS-adjacent identity frameworks both document this point.

What eIDAS and its peers say about this kind of check

The European regulatory anchor is eIDAS, which classifies electronic identification into three trust levels (Low, Substantial, High) based on the rigor of the enrollment process and the resistance of the authentication mechanism to credential misuse. A CAMARA KYC Match response sits somewhere between Low and Substantial depending on the operator's original KYC process. In a jurisdiction where SIM issuance requires presented-in-person national ID verification, the match can reasonably be treated as Substantial for attribute verification. In a jurisdiction where SIM issuance accepts self-declared attributes verified only by SMS to a prior number, the match is closer to Low.

The 2022 analysis of 156 pages of eIDAS consultation feedback documents a repeated pattern: cross-border recognition of electronic identification is gated on the enrollment rigor of the original issuer, and stakeholders frequently discovered mismatches between what one Member State's implementation assumed and what another's delivered. KYC Match inherits exactly this problem. A "match" response from a Nigerian operator does not carry the same weight as a "match" from an Austrian one, and no amount of API-schema uniformity changes that. The content of the subscriber record is set at issuance, in the local regulatory context.

The broader digital-identity literature makes the same argument from a financial-inclusion angle. The analogue-to-digital KYC progression frames the identity layer as a bottleneck for financial access in markets where document KYC fails for a meaningful share of the population. In those markets, particularly across most of sub-Saharan Africa and parts of South Asia, the SIM is often the strongest available proof of a consistent identity. SIM-issuance KYC has been performed by operators under local-regulator rules that, while less exacting than European standards, still represent more verification than most alternatives.

The reasonable uses

KYC Match is useful in specific flows.

Attribute corroboration at onboarding: a new user claims a name, birth date, and phone number, and the relying party checks the match. A mismatch is a red flag, signalling the user has given a name that does not agree with the operator's record. The flag does not prove fraud, but it is a signal worth combining with other verification steps. A match is corroborating evidence that the attributes are at least consistent with a previously verified record.

Account recovery in a steady-state relationship: an existing customer claims they have lost access and provides the phone number they originally registered with. A KYC Match against that number verifies the claimed attributes agree with the operator's record, which reduces the class of recovery attacks where the attacker guesses the phone number is a recovery channel but does not know the registered name or birth date.

Regulatory-reporting backfills: in some jurisdictions, the relying party is required to demonstrate that a customer's claimed attributes were checked against a telecom-issued identity. KYC Match provides a logged, timestamped check with a clear audit trail.

Duplicate-account detection: matching the same attributes against many phone numbers, where permitted under data-protection law, can surface account-farming patterns at onboarding. This use is regulatorily constrained and should not be attempted without a legal review.

The unreasonable uses

KYC Match is not identity verification.

The API does not confirm that the person presenting attributes to the relying party is the subscriber of record. A family member using another family member's phone, a secondary SIM on a shared subscription, a reseller device handed to an end user without a fresh KYC event: all of these produce a "match" response that tells the relying party nothing useful about the human on the other end. Legal-literature analyses of electronic identification have repeatedly flagged this confusion between attribute verification and identity verification.

The API also does not confirm the attributes are truthful in the broader world. If the operator registered the subscriber under a forged national ID, the subscriber record contains the forged attributes, and KYC Match will confirm a "match" against the forgery. The match is reliable against what the operator has on file, not against external ground truth.

The API does not provide step-up authentication. A relying party facing a high-value transaction should not treat KYC Match as a sufficient authentication step. At minimum, pair it with a possession factor like silent auth, push approval, or SMS OTP as a fallback, and treat the KYC Match response as an attribute check rather than a login check.

How to read the response structure

A well-designed KYC Match integration reads the response at two levels.

At the attribute level, the match or no-match per claimed attribute is the first-pass signal. A no-match on family name is a stronger signal than a no-match on address, because families change addresses often and operators update at variable cadence. Names and dates of birth change rarely, and a mismatch on either is closer to a flag than to a stale record.

At the confidence level, where the implementation returns one, the tolerance on text matching matters. Diacritics, transliteration, hyphenation, and married-name changes produce near-matches that some implementations report as high confidence and others as low. A relying party that accepts the response without understanding the implementation's matching semantics will under-flag or over-flag in ways that correlate with demographic groups, which is both a product problem and a compliance problem.

The best mitigation is to request the most restrictive match the operator supports, log the attributes as sent and the attributes as held, and handle the edge cases like diacritical normalisation, hyphen handling, and common transliterations at the relying party rather than trust the operator to handle them consistently across deployments.

How Tensormobile ships KYC Match

TensorAuth KYC Match implements the CAMARA schema. For subscribers on the Tensormobile home network, the response is drawn from the subscriber record populated at SIM issuance under HAKOM's KYC rules for licensed EU telecom operators. For subscribers on federating operators, the response is passed through from the home operator's implementation.

The data source per subscriber is published in the response (home-operator record or federating-operator record), so the relying party can weight the response according to the originating regulatory regime. Tensormobile does not normalise responses across jurisdictions. An Austrian operator's "match" and a Nigerian operator's "match" are returned as they come, with the originating jurisdiction attached.

The eIDAS trust-level mapping is documented for home-network responses. For federating operators, that mapping is a function of the federating operator's issuance process, not Tensormobile's, and is not normalised on our side. An integrator building for a specific jurisdiction should consult that jurisdiction's regulator on which trust level the KYC Match response maps to.

The defensible claim worth making is narrow: KYC Match confirms that a claimed name and date of birth agree with the telecom operator's subscriber record for that MSISDN, subject to the operator's original issuance KYC rigor in the jurisdiction of issuance. Shorter framings like "verified identity," "KYC in one call," or "instant identity check" compress the API's actual reach in ways the literature and the regulatory frameworks do not support. Integrators who design against the narrow claim build flows that work correctly when the API matches and degrade safely when it does not. KYC Match is a useful API when integrated to its actual scope.