Qualification, Credit & KYC

Before an order is accepted, four questions must be answered. Can this address get the service? May this person buy this offer? Will they pay? Are they who they say they are? CRM puts the questions to the customer and records the answers. In almost every estate the answers themselves come from somewhere else: the network inventory, the catalog’s rules, a credit engine and an identity-verification service.

Four checks, four owners

Credit at the point of sale

Credit matters wherever the operator carries risk before it is paid: postpaid plans billed in arrears, and handsets paid for in instalments. The decision is rarely yes or no. It is usually one of: approve; approve with a deposit; approve with a spending limit or fewer lines; offer prepaid or SIM-only instead; decline. Prepaid carries no credit risk, which is one reason it needs no credit check.

• The bureau supplies data; the operator’s own rules turn it into a decision. Those rules belong to finance or billing, not to CRM.
• In some countries a handset paid for in instalments is regulated consumer credit, with its own checks and disclosures. That is a legal question to settle per market, not a CRM setting.
• The check can run early — at the basket, to avoid disappointing the customer later — but the order must still be refused if the result is missing or stale when it is submitted.

KYC and SIM registration

Many countries require the operator to verify a person’s identity before activating a SIM. GSMA counted mandatory SIM registration in 155 countries in 2020. Where it applies it covers prepaid as well as postpaid, which is why prepaid systems that once held only a phone number now hold identity data. With eSIM there is no shop counter, so verification moves online: a photo of an identity document, a check that the person is present, and a decision from a verification service.

• CRM stores the outcome and a reference to the evidence, not necessarily the document image itself. Keeping copies of identity documents is a data-protection decision with its own retention rules.
• KYC happens again later: a SIM swap or a change of account holder is a point where fraud is attempted, and many operators re-verify there.
• TM Forum has no dedicated KYC API. Identification sits on the party (TMF632) and digital identity on TMF720; the verification itself is an integration with a specialist service.

Who holds the record

Anti-pattern: checks as screens, not gates

• Why organisations choose it: it is the quickest way to add a check, and the channel team owns the screen.
• What must hold true for it to work: every order comes through that one screen, and the check never fails silently.
• How it fails: a new channel launches without the check, or an outage lets orders through unchecked. Bad debt and failed installations appear weeks later.
• Long-term cost: the same rule implemented in every channel, each slightly different, and no reliable record of which orders were checked.

The fix is to make the check a gate where the order is accepted: COM refuses, or holds, an order whose required results are missing or out of date. The channel can still run the check early for a better experience; the gate makes sure it happened. This is also how this module reconciles with Section 13.9, which places the credit check in COM: the assessment can run early, the enforcement belongs at order acceptance.