Yakeen vs Nafath vs Wathq: Saudi Identity APIs Compared

Every team building a regulated product in Saudi Arabia hits the same wall in the same week. Someone in the room says "we need to verify the customer's identity," everyone nods, and then the architecture goes sideways for two months — because "verify the identity" describes three completely different services, each run by a different operator, each with its own access process, its own billing model, and its own regulator watching it.

We have watched this play out on fintech onboarding flows, insurance quote engines, and B2B marketplaces. The pattern is always the same: a team integrates Nafath, ships it, and then discovers at compliance review that Nafath never told them whether the name the customer typed matches the civil registry. Or the reverse — a team buys Yakeen access, builds a beautiful data-matching pipeline, and then finds out they have no way to prove the person sitting at the keyboard is the person whose ID number they just queried.

These are not competing products. They are different layers. Here is how to tell them apart before you write any code.

The three layers, stated plainly

Nafath (النفاذ الوطني الموحد) answers: is this person here, right now, and do they consent?

Nafath is authentication. It is the national single sign-on operated by Elm on behalf of the Digital Government Authority. The user is redirected to Nafath, approves the request in the Nafath app or via an SMS-delivered code, and your system receives a signed assertion over OAuth2/OIDC that a specific national ID or Iqama holder actively approved this transaction.

What Nafath gives you is presence and consent. What it does not give you is a rich, structured view of that person's registry record.

Yakeen (يقين) answers: does the data this person gave me match the government record?

Yakeen is attribute verification. It is operated by Elm and reads from the National Information Center (NIC) — the Ministry of Interior's civil registry — plus Saudi Post for national address data. You send an identifier (national ID for citizens, Iqama for residents, visa number for visitors) along with a corroborating field, and you get back the authoritative record: full name in Arabic and English, date of birth, gender, nationality, ID status and expiry, national address, and for residents, sponsor and occupation details.

What Yakeen gives you is truth about the data. What it does not give you is any evidence that the person supplying that data is its owner.

Wathq (واثق) answers: is this company real, and is this person allowed to act for it?

Wathq is entity verification, operated by Thiqah in partnership with the Ministry of Commerce. It resolves a commercial registration (سجل تجاري) into company status, activities, capital, and — critically — the list of authorised signatories and managers. It is the company-side counterpart to the two person-side services above.

We covered the business-verification side in depth in our guide to Maroof and Wathq for merchant verification, so this article stays on the person side.

The matrix that ends the argument

Put your actual requirement in the left column and the answer falls out.

That last row is the one that decides most architectures. Nafath requires a live human to approve a push notification. Yakeen and Wathq are server-to-server lookups that work in a nightly batch, in a back-office review queue, or in a fraud-scoring job at three in the morning. If your use case is "re-screen our existing book of 40,000 customers for expired IDs," Nafath is structurally the wrong tool and no amount of engineering will fix that.

Most regulated products need two layers, not one

The mature pattern in Saudi fintech onboarding is a handshake between the two:

1. Nafath establishes presence. The user authenticates and consents. You now hold a signed assertion tied to a specific national ID or Iqama number.
2. Yakeen enriches and validates. Using the identifier Nafath just proved, you pull the authoritative record and pre-fill the form — or you compare it against what the user typed and reject on mismatch.
3. Wathq is added only if the account is a business account, to resolve the CR and confirm the individual from step 1 appears in the authorised-signatory list.

Notice the ordering. Yakeen after Nafath, not before. Running Yakeen first, on an identifier a user simply typed into a form, tells you only that the number belongs to someone real — it tells you nothing about whether it belongs to the person in front of you. That distinction is exactly what identity-theft-driven fraud exploits, and it is the single most common design flaw we see in KSA onboarding reviews.

The access model is the real project risk

Here is where budgets and timelines actually go wrong: none of these services are self-serve. There is no signup page, no credit-card checkout, no free tier you can start prototyping against this afternoon.

Yakeen access is brokered and entity-bound. You obtain it either directly through Elm or via an authorised reseller such as Rabet, and for smaller companies through the SDAIA and Monshaat باقة رواد (Rowad) package aimed at startups and SMEs. Whichever route you take, three constraints follow:

• The credentials belong to the establishment, not to you. Access is issued against a commercial registration and a stated purpose. If you are an agency building for a client, the client subscribes and the client owns the credentials. You cannot resell your own access across multiple customers, and structuring the project as though you can is how integrations get shut off post-launch.
• You are billed per query. Published reseller pricing for adjacent Elm verification services sits around SAR 2 per successful hit, with rate ceilings in the region of 120 queries per minute. Whatever your exact tier, the architectural consequence is fixed: every Yakeen call is a line item, so cache aggressively, deduplicate at the application layer, and never put a lookup inside a retry loop that a client can trigger.
• Lead time is measured in weeks. Subscription paperwork, purpose justification, and technical onboarding all precede your first sandbox call. Plan for it in the schedule rather than discovering it in sprint three.

The protocol is older than your stack. Yakeen is a SOAP/XML service. The publicly circulating integration documents describe operations along the lines of citizen info by national ID, alien info by Iqama, and separate address-lookup operations per identity type — one operation per data need, rather than one flexible query. Nearly every serious integration therefore puts an internal REST facade in front of it that speaks JSON to your product and XML to Elm. Budget for that adapter, its schema mapping, and its error translation. It is not a wrapper you write in an afternoon.

The compliance constraints nobody reads until audit

SAMA made Yakeen optional, and made consent mandatory. SAMA circular 371000018071, dated 23 November 2015, permits banks to verify customer identity electronically through Yakeen. Two conditions in that circular have direct architectural consequences: prior customer approval must be obtained before accessing identity information electronically, and the customer bears no additional fee for it. If your consent capture is a checkbox buried in terms and conditions, you do not have the consent the circular describes.

A Yakeen call does not discharge your periodic KYC refresh obligation. The same circular is explicit that using the service must not undermine periodic identity-update requirements. Teams routinely assume that because they can now re-query the registry on demand, the scheduled refresh cycle disappears. It does not. Build the refresh job anyway.

PDPL applies to everything you retrieve. Pulling civil-registry attributes is processing of personal data under Saudi Arabia's Personal Data Protection Law. You need a lawful basis, a defined retention period, and a genuine answer to why you stored the full record rather than a verification result. Our practical guidance is to persist a boolean outcome plus a timestamp and a request reference, and to discard the payload once the match is decided — you keep your audit trail and shrink your breach surface at the same time. Where cross-border processing is involved, the transfer rules bite too; we walk through those in Saudi PDPL and cross-border data transfer.

A design sketch, not an API contract

The shape below is deliberately protocol-agnostic — treat it as the internal interface your product should code against, with the SOAP details isolated behind the adapter. Exact operation names and field lists come from the integration pack Elm issues you at subscription.

// Your internal facade — stable, JSON, cacheable.
interface IdentityCheck {
  // Layer 1: who is present (from the Nafath assertion)
  subjectId: string;          // national ID or Iqama, proven by Nafath
  assertionRef: string;       // signed OIDC token reference
 
  // Layer 2: what the registry says (from Yakeen, via the adapter)
  registryMatch: boolean;     // did the claimed fields match?
  idStatus: "valid" | "expired" | "not_found";
  checkedAt: string;          // ISO timestamp for the audit trail
}
 
// Store this. Do not store the raw registry payload.

The rule of thumb: your product should never import a SOAP client. It should call one internal endpoint that returns the object above, and everything ugly — XML envelopes, charge codes, per-operation quirks, retry policy, cost accounting — lives in a single service you can rate-limit and observe on its own.

What this means for your roadmap

If you are scoping a Saudi launch, three decisions belong in week one rather than month three: which layers your regulator actually requires, who legally holds the Yakeen subscription, and where the adapter lives in your architecture. Getting those wrong is not a bug you patch — it is a rebuild.

The same layered thinking applies across the rest of the KSA government platform stack. Payroll systems hit Mudad and WPS, HR systems hit Qiwa and Nitaqat, and residency workflows hit Muqeem. Every one of them shares the same access pattern: brokered credentials, per-query billing, an older protocol than you expected, and a regulator's circular that changes what your code is allowed to do.

Not sure which identity layer your product actually needs? We map the requirement against your regulator, your data-residency position, and your existing stack before anyone opens a subscription — usually in a single working session. Tell us what you are building and we will tell you honestly which of these three you need, and which you do not.