Know Your Customer (KYC) & KYC Match API

What is KYC?

KYC stands for Know Your Customer. It describes the processes organisations use to establish and verify information about customers before or during a business relationship.

KYC is particularly important in regulated or trust-sensitive industries such as:

 

• banking;

• payments;

• fintech;

• insurance;

• cryptocurrency;

• telecommunications;

• marketplaces;

• and other services exposed to identity fraud.

 

The exact KYC requirements vary by industry, service, customer type and jurisdiction.

Depending on the context, KYC processes may involve collecting and verifying attributes such as:

 

• full name;

• given name;

• family name;

• date of birth;

• address;

• postal code;

• nationality;

• country of birth;

• identity-document number;

• identity-document type;

• document expiry date;

• email address;

• and other customer information.

The GSMA Open Gateway KYC specification describes KYC as the process of a business verifying the identity of its clients and assessing suitability and potential risks associated with the business relationship.

What is the KYC Match API?

The KYC Match API is a Network API that allows an authorised service provider to compare identity information supplied by a customer with corresponding information already held and verified by the customer's Mobile Network Operator.

The application supplies one or more supported identity attributes. The operator compares those values against its customer record associated with the mobile line. The API returns the result of the comparison.
Importantly, KYC Match is designed primarily to answer:

"Does the information provided by this customer match the information the operator has already verified?"

It is not designed to return the operator's stored customer information.

CAMARA explicitly states that KYC Match returns per-attribute outcomes rather than underlying operator-held identity values.

This makes KYC Match different from a customer-data retrieval service. For retrieving supported operator-held attributes, CAMARA defines a separate KYC Fill In API. For age-threshold checks, CAMARA defines KYC Age Verification.

How does the KYC Match API work?

The enterprise first collects customer information through its normal onboarding, verification or account-management process.

For example, a customer may enter:

name;
date of birth;
address;
email;
nationality;
identity-document information.

The application obtains the required API authorisation. It then submits selected attributes to the KYC Match /match operation. The operator identifies the relevant mobile subscriber and compares each submitted attribute with its own verified KYC record. The API returns match results only for the attributes that were requested.

The current CAMARA specification defines three principal result values:

true — the submitted value matches the operator record;
false — the submitted value does not match;
not_available — the operator does not have the attribute available for validation.

For selected string values, an API provider may also return a match score when the result is not an exact match.

The score represents the degree of similarity.

In the current specification, an exact match corresponds to true, while a non-exact result may be accompanied by a score below 100 where supported.

Supported KYC Attributes

 

The exact attributes supported by an operator may vary.

The CAMARA specification includes fields related to information such as:

phone number;
identity-document number;
identity-document type;
identity-document expiry date;
bank-account number;
complete name;
given name;
family name;
middle names;
family name at birth;
address;
street name;
street number;
postal code;
region;
locality;
country;
house-number extension;
birthdate;
email;
gender;
city of birth;
country of birth;
nationality.

A service provider should not assume every network holds or exposes every field. A not_available result exists specifically because a particular attribute may not be available for validation.

 

Attribute-Level Matching

 

KYC Match does not simply return a single overall "customer verified" Boolean.  The response can provide an outcome for each requested attribute.

For example:

name → true
date of birth → true
postal code → false
email → not_available

This allows the enterprise to make its own risk or onboarding decision.

A bank could determine that a name and birthdate match is sufficient for one low-risk process but require stronger verification for a high-risk financial product. The API provides evidence. The enterprise defines the business decision.

Match Scores

 

Some identity information can differ slightly even when it refers to the same person.

 

For example:

 

"Mohamed Al Hassan"
"Mohammed Al-Hassan"

or:

"123 Main Street"
"123 Main St."

 

A strict character-for-character comparison may produce a false mismatch. The CAMARA API therefore supports optional match-score results for selected attributes.

 

Where supported, the score gives the application information about how similar a non-exact submitted value is to the operator-held value. However, the match score is not itself a universal KYC risk score. The enterprise remains responsible for deciding what similarity level is acceptable for its use case.

 

Phone-Number Identification

 

KYC Match is associated with the customer record bound to a mobile phone number.
Depending on the authorisation model, the phone number may be:
supplied explicitly in the API request; or identified through a user-specific access token.

 

The GSMA API reference explains that with certain two-legged access-token scenarios, the phone number must be supplied, while a three-legged user-specific token can identify the subject directly. If both are supplied in a context where the token already identifies the user, the implementation applies the API's identifier-consistency rules.

 

Authentication, Authorisation and Consent

 

KYC information is personal information. Access must therefore be controlled carefully. The CAMARA specification references the CAMARA Security and Interoperability Profile and Identity and Consent Management framework.

 

The actual authorisation flow depends on the service provider's declared purpose, the operator, the API provider and the applicable legal framework.

 

Where personal data is processed and users exercise rights through opt-in or opt-out mechanisms, the specification requires the applicable three-legged token model.

 

This ensures that KYC Match is not treated as an unrestricted subscriber-information database.

 

Why is KYC Match important for Mobile Operators & Enterprises?

 

Digital onboarding creates a difficult balance. Enterprises need confidence that customers are providing accurate information. But excessive verification steps can make registration slow and expensive.

 

Traditional processes may require:

identity-document uploads;
manual document review;
OCR;
database checks;
video identification;
support-agent review; or
repeated customer data entry.

Mobile operators may already hold customer information that was collected and verified when the mobile subscription was established or maintained.  KYC Match allows authorised service providers to use this operator-held information as an additional verification signal without requiring the operator to disclose the actual stored record.

 

CAMARA identifies onboarding, account creation, KYC refresh, fraud prevention, account verification, eCommerce and regulated-service access as representative use cases.

 

Key Benefits / Features of Know Your Customer

 

• Operator-assisted identity verification

   

• Attribute-by-attribute matching

   

• true, false and not_available outcomes

   

• Optional similarity scores

   

• Privacy-preserving comparison

   

• No need to disclose underlying operator KYC values

   

• Supports digital onboarding

   

• Supports KYC refresh

   

• Supports profile verification

• Supports fraud detection

• Supports synthetic-identity detection

   

• Supports account recovery

   

• Supports eCommerce and marketplace verification

   

• Standardised CAMARA API

• GSMA Open Gateway exposure

• Integration with Number Verification

   

• Integration with SIM Swap

   

• Integration with Device Swap

   

• Lower dependency on manual review for eligible cases

Examples of KYC Match API Use Cases

Digital banking onboarding

 

A prospective banking customer submits:

 

mobile number;
full name;
date of birth;
address; and
nationality.

 

The bank performs its normal identity and compliance process. As an additional source, it calls KYC Match. The operator returns attribute-level results. If the name, birthdate and address match, those signals can strengthen confidence in the submitted profile. If important fields do not match, the bank can request additional documentation.

 

KYC Match does not determine whether the account should be approved. It supplies an independent operator-derived comparison.

Fintech registration

A fintech application can use KYC Match during registration to identify discrepancies before creating an account. This may reduce fraudulent or inaccurate sign-ups and reduce the number of customers who later require data correction.

 

Synthetic identity detection

A fraudster may combine real and fabricated personal information to create a synthetic identity.
Comparing the supplied attributes against an operator's verified customer information may expose inconsistencies.

CAMARA specifically lists synthetic identity and identity-theft detection among the fraud-prevention applications of KYC Match.

KYC refresh

Regulated businesses may periodically review customer information. Instead of requiring every customer to repeat a full manual process, KYC Match can be used as one signal to determine whether selected customer details remain consistent with operator-held records. The required process remains subject to local regulatory obligations.

Account recovery

A customer asks to recover an account. The application can compare selected identity information through KYC Match and combine it with:

Number Verification;
SIM Swap;
known-device information;
passkeys;
biometrics;
customer-support checks.

This provides several independent signals rather than relying solely on SMS possession.

Marketplace seller verification

An online marketplace onboarding a merchant or seller can compare submitted identity information with operator-held information. A mismatch may trigger additional review before the seller is allowed to receive payments or list high-risk products.

High-value eCommerce

A marketplace can use KYC Match as an additional risk signal during high-value purchases or profile modifications.

KYC Match vs. KYC Fill In

These are different APIs. KYC Match asks:
"Does the information I already have match the operator's verified information?"

It returns match results.

KYC Fill In asks the operator to provide selected customer attributes, where the capability, permissions and legal basis allow it.

KYC Match is therefore primarily a comparison API.

KYC Fill In is a data-retrieval or form-prefill capability.

KYC Match vs. Number Verification

 

Number Verification confirms an association between the authenticated SIM/device context and a mobile number. It does not validate a customer's full legal identity.

KYC Match compares identity attributes against operator-held KYC data.

For example:

 

Number Verification: "Is this device/subscription associated with +44xxxxxxxxxx?"

KYC Match: "Does the name, birthdate and address supplied for the customer match the operator's verified account information?"

 

The two APIs therefore solve different problems and can be used together.

 

KYC Match vs. SIM Swap

 

SIM Swap is a fraud-risk signal related to changes in control of the mobile subscription. KYC Match is an identity-data comparison.

A customer may have perfect KYC Match results but have experienced a SIM swap an hour ago.

Conversely, a long-established SIM could be associated with customer data that does not match the information submitted to an application.

Using both provides different dimensions of risk.

KYC Match vs. Full Regulatory KYC

A successful KYC Match does not automatically mean that an enterprise has completed every legal or regulatory KYC obligation. The API provides an identity-verification signal.

The enterprise remains responsible for determining:

 

• what customer due diligence is required;

   

• whether identity documents must be collected;

   

• whether sanctions or PEP screening is needed;

   

• whether source-of-funds checks apply;

   

• what records must be retained;

   

• what legal basis applies;

   

• what other regulatory controls are mandatory.

CAMARA itself positions KYC Match as one signal that can support regulated-service and customer-due-diligence processes, subject to local requirements.

Common Questions about KYC Match

1. Does KYC Match reveal the operator's customer data? No. The Match API returns comparison outcomes rather than the underlying operator-held values.

2. What does true mean? The submitted attribute matches the corresponding operator-held value.

3. What does false mean? The submitted value does not match.

4. What does not_available mean? The operator does not have the attribute available to validate.

5. Can KYC Match return similarity scores? Yes, for supported string attributes and provider implementations, a non-exact comparison may include a match score.

6. Does a high match score mean the customer has passed KYC? Not automatically. The enterprise determines how API results are interpreted within its own KYC and fraud framework.

7. Does KYC Match verify a phone number? The phone number identifies or relates to the subscriber whose KYC record is being checked, but Number Verification is the dedicated API for confirming the number associated with an authenticated device/subscription.

8. Can I use KYC Match to retrieve the customer's address? No. KYC Match compares the address you supply. KYC Fill In is the separate capability for retrieving authorised attributes.

9. Does the API replace ID-document verification? Not necessarily. An organisation may still need document verification depending on its risk and regulatory obligations.

10. Is consent required? The answer depends on the data, legal basis, purpose, jurisdiction and implementation. CAMARA provides common identity and consent rules, while the provider and enterprise remain responsible for the applicable legal requirements.

11. Can KYC Match prevent all identity fraud? No. It should be combined with other controls such as Number Verification, SIM Swap, Device Swap, document verification, sanctions screening, behavioural analytics and transaction-risk monitoring as appropriate.

12. Is KYC Match available on every network? No. Commercial availability varies by country, operator and provider. CAMARA directs users to GSMA Open Gateway launch information for availability.

 

Related Terms

Network APIs;  KYC Age Verification; Identity Verification; Customer Due Diligence; Digital Identity; Mobile Identity; Number Verification; SIM Swap; Device Swap; Synthetic Identity; Identity Theft; Fraud Prevention; Mobile Network Operator; MSISDN; OAuth 2.0; OpenID Connect; Three-Legged Access Token; Consent Management; CAMARA; GSMA Open Gateway. 

 

Sources 

CAMARA KYC Match GitHub Repository

CAMARA Know Your Customer Match Overview  

CAMARA KYC Match OpenAPI Specification

GSMA Open Gateway KYC API Reference

CAMARA KYC Fill In

CAMARA Identity and Consent Management

GSMA Open Gateway API Descriptions

Last Updated: October 2026