Merit ID · Partnership assessment · Angles 1 and 2
Which World-Check product fits, what Merit has to build before it can call one, and where the work belongs on the Merit ID roadmap.
Corrected after Julie Barbier's note in #newbiz-lseg: Merit ID is not the same as the partner programmes, and Merit owns the data in Merit ID. v1.0 applied a partner-programme constraint to Merit ID and put the blocker in the wrong place. Rewritten: sections 0 (new), 1, 2, 4.5 (new), 5, 6, 7.5, 7.6, 7.7, 8 and 9. Unchanged: the product choice in section 3, the route B flow in section 4, and sections 7.1 to 7.4.
Four conclusions. The rest of this document is the evidence for them.
Verify is a stateless real-time screening API and LSEG runs the matching. On Demand ships the database and expects the buyer to match against it, which would make Merit a KYC data operator. Julie's own framing rules that out.
Merit ID is Merit's own product, and Merit owns the data in it. A partner programme member, for example Al Fursan, belongs to the partner. Treating the second as a fact about the first was v1.0's error, corrected in section 0.
Merit holds no partner member identity because Merit agreed not to hold it. TR-05, decided 3 August 2026: no member tier, identity, or any other Al Fursan member data is ever stored on Merit's side. Extending screening to those members is a negotiation per tenant, not a build.
The Merit ID member signs up with Merit and consents to Merit. No partner sits in that chain, so no permission is missing. Merit ID holds a handle, an email, a phone and a KYC status, and none of the attributes a screening call needs. Merit chose that scope, and Merit can change it. One product decision, taken once, opens the route.
Verify stores nothing. So a partner can pass attributes for a single call, and Merit can keep only the reference and the outcome. That is compatible with the commitment Merit already made, and it needs no new data-sharing rights.
On the B2C Super App the member belongs to Merit, and asking is a product decision, not a negotiation. Android is live, public launch was end of July, and the target is 125,000 monthly transacting users by December. The base is small today, which is the honest limit, not a blocker.
Merit already runs KYB plus a PEP and sanctions watchlist check on sellers and partners, live since February 2026 through Themis. On the business side LSEG meets an incumbent. Section 7 has the full answer.
The closest owner is Merit ID membership, H2 2026, and its scope is written as checkout as a pay method. Section 6 proposes widening that line rather than opening a new one.
This is the partner programme plane, for example Saudia and Al Fursan. The tenant holds everything a screening call needs, and Merit holds only a session and a member identifier. The line between them is a decision Merit took on purpose, not a gap in the schema, so the people who can move it for a partner member are Julie, Fadi and whoever holds each tenant contract. Merit ID's own members are a different population, with a different gap. Section 02 covers it.
v1.0 read this as one gap, data rights, on one population. It is two gaps, on two different populations, and only one of them is a data-rights problem.
merit_id handleemail verifiedphone verified E.164kyc_status None, Level_1, Level_2password_hashavatar_urlSystem Specification v1.1, section 6.1. That is the complete list, for every Merit ID member.
None of these columns exist. That is the real gap, and it is the same shape on both populations.
A Merit ID member signs up with Merit and consents to Merit. No partner sits in that chain, so no permission is missing. Adding the screenable columns and asking for the attributes at onboarding, with consent, is a normal product change on a product Merit owns.
Merit holds only the tenant's member identifier, resolved live at sign-in. A member ID is not a screenable attribute. World-Check matches on names, dates of birth and documents, and Merit may not hold any of those for a partner member.
| Rule | What it says |
|---|---|
| TR-05 decided 3 Aug 2026 |
There is no cached tier and no member data sync. No member tier, identity, or any other Al Fursan member data is ever stored on Merit's side. |
| TR-02 | Member tier is resolved live from the tenant's own loyalty system, for Al Fursan the loyalty API operated by Accenture. Merit holds no copy of it. |
| TR-06 | The anchor attribute is the tenant's own member identifier, for Al Fursan the Al Fursan member ID. Email and phone must not take that role. |
| TR-07 | Campaign creation must not depend on Merit holding any view of the tenant's membership base. |
| Section 8.1 | Merit only learns a member exists when they sign in. Sizing an audience would need the tenant's full member list. |
All five from Ecommerce/PRD_Promo_Engine_V1.md, and all five are written
about Al Fursan member data held by the tenant. None of them names Merit ID, and none of
them applies to a member who signed up with Merit. v1.0 used these rules to explain Merit ID.
That was the error.
Merit holds the tenant's member identifier, resolved live at sign-in. A member ID is not a screenable attribute. World-Check matches on names, dates of birth and documents. There is no lookup from a Saudia member number to a sanctions list, and there should not be.
On Merit's own base this is a product question, and Merit answers it alone: nobody has to agree. On the partner side the people who can change it are Julie, Fadi and whoever holds each tenant contract. No sprint changes that half.
v1.0 led with the partnership question and filed the owned route third, which reads as though Merit is blocked everywhere. Merit is blocked on the partner base and unblocked on its own, and the unblocked one has not been started. The size limit is real: the B2C Super App has Android live, a public launch at the end of July, and a target of 125,000 monthly transacting users by December. That makes the partner conversation the second problem, not an unnecessary one.
The operations playbook describes Level 2 as a support agent matching an uploaded selfie and
national ID against existing records. So kyc_status = Level_2 records a human
decision. Even where a member does hand over a document, the structured attributes are not kept.
The product page states Merit is a Technology Service Provider and holds that position by design. Screening through a licensed third party is consistent with that. Ingesting the World-Check database and running matching in-house is not.
LSEG sells three real products under one marketing umbrella. The names overlap and the choice matters, because two of them put the sanctions list in a different place.
The list never moves. Merit sends one question and gets one answer. LSEG keeps the database, the matching engine, the refresh cycle and the regulatory weight that comes with them.
The whole database crosses into Merit. From that moment Merit owns the matching quality, the false-positive rate, the refresh cycle and the regulatory exposure. That is a different company.
| World-Check Verify | On Demand (= Data API) | World-Check One | |
|---|---|---|---|
| What it is | Stateless real-time screening API, launched Oct 2025, built with AWS | Structured delivery of the World-Check database: single record, bulk, delta | Screening software with a case-management UI, plus an API |
| Integration | REST, synchronous, one record per call | REST, real-time and batch, change feeds | REST, synchronous and asynchronous |
| Who matches | LSEG | The buyer | LSEG |
| Stores screening data | No, explicitly none | n/a | Yes, cases persist |
| Ongoing monitoring | Not offered | Delta feeds, buyer builds it | Yes, webhook alerts |
| Case management UI | None | None | Included |
| Auth | OAuth 2.0 bearer | Not published | HMAC signing, RFC 2104 |
| Data residency | In-region AWS hosting | Not published | Not published |
Verify is point-in-time. A member screened clean at onboarding who becomes a sanctioned person or a PEP two years later never re-flags, because nothing is monitored. Regulated clients ask for ongoing screening. Two ways exist to close the gap, and the choice is commercial, not technical: re-screen on a schedule through Verify and pay per call, or add World-Check One for the monitored population. Q2 in section 8 puts the pricing question to LSEG.
Screening sits between identity resolution and the eligibility decision. It never sits in the payment path.
This is route B. The tenant sends the attributes for one call, Merit passes them through and stores none of them, and LSEG stores none of them either. The dashed line is the audit trail, and it carries a reference and an outcome, never an attribute.
A synchronous external call in the payment path would put LSEG's availability in front of Merit's revenue. Screening happens when a member moves to a verified tier, or when a regulated tenant onboards them. The result is cached against the identity.
Screening returns candidates, not verdicts. Name matching against sanctions and PEP lists produces false positives at a rate that makes automatic refusal unacceptable. So the design assumes a queue and a human, and Merit builds the adjudication view because Verify ships no UI.
The bank's auditor asks who was screened, when, against what, and who cleared the match. Merit stores the reference id, the timestamp, the categories returned and the adjudicator. This table is what makes Merit ID sellable to a regulated client, more than the API call is.
World-Check goes behind a screening-provider interface. Merit ID already applies this pattern to notifications, where the orchestrator selects push, WhatsApp or SMS. Same shape. It costs little now and prevents a rebuild when a client demands a different vendor.
The flow above is route B, where a tenant presents the attributes for one call. Route C is now the primary recommendation, and its flow is different enough to be worth writing down. It is also shorter.
| Step | What happens | Who holds the data |
|---|---|---|
| 1 | At onboarding, or at the point of identity elevation, Merit ID asks its own member for name, date of birth, nationality and a document, with consent | The member, consenting to Merit |
| 2 | Merit stores them against the Merit ID record | Merit, deliberately, under consent and the residency commitment |
| 3 | Merit calls Verify with an OAuth 2.0 bearer token, reading from its own record | In transit |
| 4 | A match list, categories and a reference id come back | LSEG stores none of it |
| 5a | No match. The member is cleared, and the reference is written to the screening result store | Merit |
| 5b | A match returns. The member is held and queued for a human reviewer | Merit |
Route B's whole design is that Merit holds nothing. Route C reverses that for Merit's own members, which is allowed because they consented to Merit. It brings real obligations: residency in Jeddah or Riyadh under SAMA and NCA, a retention policy, and a deletion path. Legal has not confirmed this yet.
Steps 2 and 3 of the route B flow disappear, so there is no dependency on a partner system being available at screening time.
Section 3 names point-in-time screening as Verify's one serious weakness. Under route B Merit cannot fix it alone, because every re-screen needs the tenant to present the attributes again. Under route C Merit holds the attributes, so it can re-screen on a schedule without asking anyone. The owned route is the only one on which the monitoring gap can be closed by Merit's own decision. The cost is per-call pricing, question 2.
Nothing in section 4 can run until Merit can put a name into a screening call. There are three ways to get one. Two of them are commercial. One of them is not, and that is the one v1.0 filed last.
Route C goes first, and needs nobody's agreement. It is the only route with no counterparty: Merit owns the member, so the question is whether Merit asks, not whether Merit is allowed. Route B is the recommendation for the partner base, run in parallel. Verify's statelessness is what makes it possible: LSEG stores nothing, so Merit storing nothing is the same design rather than a compromise.
| C. Ask our own members | B. Screen without holding | A. The partner shares | |
|---|---|---|---|
| Population | Merit ID members. Merit's own. | Partner programme members | Partner programme members |
| What happens | Merit asks its own members for name, date of birth and a document at onboarding, with consent, and keeps them | The tenant passes attributes for one screening call. Merit forwards them to Verify, keeps the reference and the outcome, and never stores the attributes | The tenant passes verified identity attributes to Merit, and Merit stores them |
| Whose data rights change | None. The member is Merit's and consents to Merit. | Nobody's storage rights. Merit acts on the tenant's instruction and retains nothing | Merit's. It reverses TR-05. |
| Legal weight | Light. Consent at the point of collection, plus residency for what is now stored | Moderate. Processor terms and a purpose limitation, per tenant | Heavy. New data-sharing terms, a lawful basis, and residency under SAMA and NCA, per tenant |
| Who has to agree | Nobody outside Merit | Each tenant's legal team | Each tenant's legal team and commercial owner |
| Speed | Can start now. Bounded by Merit's own release cycle. | Fastest of the two partner routes | Slowest. Every tenant is a separate negotiation |
| Ceiling | Full KYC reuse, on Merit's own base only | Screening only. No reuse, no profile enrichment | Full KYC reuse across the programme |
| Blocker | Nothing external. A product decision, plus Verify's request schema, question 3. Then adoption: Android live, public launch end July, 125,000 MTU targeted by December | Needs each tenant's legal sign-off on Merit as processor | Reverses a decision taken deliberately six weeks ago |
It covers Merit's own members and nobody else. Today that base is small, and a bank asking about Al Fursan members is not answered by it. Route C makes Merit unblocked, not finished.
Merit still cannot screen a member the tenant never presents. Coverage becomes whatever the tenant chooses to send, and Merit cannot audit the gap. Say that to a bank rather than let them discover it.
The build is small, and it is downstream of the route decision. It is not the critical path.
That was the conflation. It is the item that makes Merit's own product screenable, it needs no tenant conversation, and its only real dependency is knowing which attributes Verify wants before Merit asks members for them. Its short-term return is small because the base is small, which is an argument about sequencing volume, not about whether it is the answer.
The main ask is not a roadmap line. It is an owner for a commercial workstream.
Does Merit ID start collecting name, date of birth and a document at onboarding, with consent. This is the unblocked half, and it needs no owner outside the product team.
For partner programme members the blocker is data rights, so the thing to assign is the negotiation, not a sprint. Nobody holds that today.
| Closest line | Window | Scope as written | Status |
|---|---|---|---|
| Merit ID membership | H2 2026 | B2C, checkout as a pay method | New, BRD drafted |
That scope mentions no screening and no identity attributes. Widen it to carry items 1 to 4 and 6, once a route is signed. Item 5, direct capture on the Super App, belongs to the B2C track, because that is where the member relationship and the consent sit.
Order Fraud Prevention Layer, Q3 2026, is an Ecom risk screen for the MGC single-key model. It screens orders, not identities. It is worth checking that the two do not build separate screening abstractions, because they would each need one.
The product page lists what Merit ID gives banks: KYC done once and reused, and lower verification cost. A bank cannot reuse a KYC decision that carries no sanctions or PEP check behind it. So screening makes the existing bank proposition true.
Under route B Merit screens without holding, which delivers the compliance outcome but not the reuse. Full KYC reuse needs Merit to hold the attributes. On the partner base that means route A, which reverses TR-05. On Merit's own base it means route C, and nothing is in the way. So the product page does not promise something Merit is not permitted to deliver. It promises something Merit has not yet built, on the population it owns.
Once screening is embedded and audited, the sentence Julie wants to say to the banks and networks in her note becomes true. The screening result store proves it.
GAV verifies bank-account ownership before a transfer, so it is a payout control. It does not belong on this roadmap line. It does belong in Merit's plan, and section 7.3 gives it a place and a priority.
Green is route C, and it is Merit's own call, no counterparty. Violet needs a signed route for the partner base, except the Super App track, which needs nobody's permission. Grey is the monitored population, priced from real volume.
A different question from angle 1, with a different answer. On the consumer side Merit screens nobody. On the business side Merit already screens, and has done since February 2026.
The roadmap records KYB and KYC through Themis, live since February 2026, for the Seller Portal and the Partner Portal. The onboarding auto-triage tags an application Low Risk or High Risk on a watchlist check against PEP and sanctions, and only a Compliance role can approve a High Risk application. So on angle 2 the LSEG conversation is displacement or layering, not greenfield.
Do not present counterparty screening to LSEG as an open gap. Merit has an incumbent, LSEG sells to this market, and they will find it. Say what runs today and ask what LSEG adds. What nobody has written down is which list sits behind that check, who supplies it, what it covers and what it costs. That is an internal question, and it has to be answered before the call rather than during it.
Five touch points across one chain. The two red ones are where Merit is exposed and where LSEG has a product that fits.
| Touch point | Control today | Gap |
|---|---|---|
| Seller and partner onboarding | KYB through Themis, plus a PEP and sanctions watchlist check | List source and provider undocumented. No beneficial owner collected anywhere. |
| Seller and supplier payout | IBAN Mod-97 checksum, an uploaded bank certificate, a warning if the account name does not match | Nothing verifies that the account belongs to the payee. |
| Order fulfilment gift cards through MGC | None live. The Order Fraud Prevention Layer is a draft PRD for Q3 2026. | The single consolidated MGC key removed per-tenant whitelisting and prepaid limits, so the old guardrails are gone. |
| Buyer and seller behaviour | Four rules, run weekly over completed orders. They block nothing. | Real-time block or hold is explicitly deferred. Detection finds the actor after the money left. |
| Issuers and alliance partners | None documented | Vodafone Egypt is named as first issuer for LMS-Lite with no vetting step recorded. |
Merit pays money out to seller and supplier bank accounts. The only controls on that account are a checksum, an uploaded PDF and a warning. A checksum proves the IBAN is well formed. It does not prove the account exists, and it does not prove it belongs to the seller. GAV does exactly that one thing, so it is the cleanest fit in Julie's whole note: the gap is specific, the product is narrow, and it needs no Merit ID work first.
LSEG's published figures do not agree with each other. One source says 21 countries, LSEG's own page says 80 percent of G20 countries with more added in phases. Neither names Saudi Arabia. A payout control that does not cover the Kingdom is not useful to Merit. That is Q8.
The Order Fraud Prevention Layer PRD is drafted, P1, for Q3 2026. It already specifies:
Allow, Review or Block, returned before the call to MGC or any external fulfilment. Rule weights and bands change without a code deploy, with per-tenant overrides. A review queue with reasons and an audit log.
The PRD's phase 2 is third-party provider integration behind the same decision interface. That is a designed vendor slot with a date on it, and a better landing point for LSEG risk intelligence than anything in angle 1.
The PRD writes a response budget of p95 under 500 ms. LSEG publishes no latency figure for any screening product, only qualitative claims. A provider that cannot answer inside that budget cannot take the slot. That is Q9.
The two halves of this note look inconsistent until you line them up. They are not, once the member population is split in two.
| Sellers and partners | Merit ID members | Partner programme members | |
|---|---|---|---|
| Who holds the relationship | Merit. They register in Merit's own portal. | Merit. They sign up with Merit. | The tenant. Saudia owns the Al Fursan member. |
| What Merit receives | CR number, VAT number, legal name, address, bank IBAN, and the representative's national ID | Handle, email, phone, KYC status. Merit chose not to ask for more. | A member identifier, resolved live at sign-in |
| Can Merit screen them | Yes, and it does, since February 2026 | Not yet, and only because the attributes were never asked for. Merit can change that alone. | No. There is no name to send, and Merit may not hold one. |
That is the whole rule, and the three columns obey it. It also locates each fix precisely. For sellers there is nothing to fix. For Merit ID members the fix is in what Merit asks for, and it is Merit's to make. For partner programme members the fix is in the relationship, and it is not.
It ran a two-column version of this table, put Merit ID members in the tenant's column, and concluded Merit could screen nobody.
The fraud and abuse document of 27 August 2026 records it plainly. Merit has no identifier shared across channels for a third-party engine to key on. Merit ID is the fix, and it has no adopter yet. The same document lists client IP at order placement as unconfirmed and not captured today, and without it one of the four rules does not run at all.
So angles 1 and 2 are not parallel tracks. Risk intelligence without a stable identity produces signals nobody can attribute to one person. Nothing can reuse those signals across products either. That is why angle 2 cannot exceed what angle 1 delivers, and why angle 1 is a partnership problem before it is a product one.
| Work | Why here | Needs LSEG? | |
|---|---|---|---|
| 1 | Decide route C: collect the screenable attributes on Merit ID, section 5 | It is the only item with no counterparty, it is Merit's own product, and it delivers the KYC reuse the product page already promises. Run the route B tenant conversation alongside it. | Question 3 first, the request schema, before Merit asks members for the wrong fields |
| 2 | GAV against seller and supplier payout | Smallest and most specific gap, no Merit ID dependency | Yes, coverage first |
| 3 | Risk intelligence into the Phase 2 slot in the Order Fraud Prevention Layer | The interface and the date already exist | Yes |
| 4 | Consumer screening at identity elevation | Needs a signed route first | Yes |
This moves GAV up, from out of scope to second. That reverses section 6, and 7.3 gives the reason.
These are the answers that change Merit's design. None of them are published, and all of them were searched for. Offered to Fadi for that conversation.
What this document does not know, stated so nobody builds on it by accident.