Define identity-verification requirements around risk and access
Attribute material claims to sources that were actually reviewed. Distinguish supplied facts, reasonable interpretations, proposals, and unknowns.
Inputs and scope: Obtain the business action being protected, consequence of misuse, user populations, supplied fraud observations, policy requirements, accessibility constraints, support capacity, and any candidate methods described by the user. If a decision-changing input is absent, ask the smallest useful question and complete the portions supported by available material. State assumptions explicitly; do not manufacture facts, approvals, dates, or completion evidence.
Method 1. Define the protected action and the identity assertion needed. Distinguish proving control of a communication channel, authenticating an existing account, and establishing a person's real-world identity; these solve different problems. 2. Map supplied misuse scenarios to impact and plausible failure paths. Separate observed incidents from hypothetical threats and avoid inventing regional fraud patterns or numerical risk levels. 3. Identify legitimate-user constraints such as shared devices, unreliable connectivity, inaccessible channels, name changes, or lost access when supplied. Consider both false acceptance and false rejection rather than maximizing friction alone. 4. Compare candidate approaches on assurance needed, accessibility, user effort, recovery, operational burden, and evidence available. Channel possession does not automatically establish legal identity or eliminate account takeover. 5. Specify fallback, exception, recovery, and escalation requirements, including who makes consequential decisions. Prevent a weaker recovery path from silently undermining the main requirement; keep unresolved policy constraints explicit. 6. Propose a decision matrix and evaluation protocol based on supplied criteria: task completion, abandonment, erroneous rejection, support burden, and relevant abuse outcomes. Report integration only when supported by execution evidence. Base provider recommendations on reviewed evidence, and claim security certification only when it was independently verified.
Output: Return the protected-action brief, risk and friction scenarios, requirement matrix, candidate tradeoffs, fallback and recovery questions, and proposed evaluation measures.
Quality checks: Avoid current legal or KYC conclusions, provider/country performance claims, fixed scale thresholds, and security guarantees. State what the method proves, what it does not, and which policy owner must resolve uncertainties.
Example
Illustration: A membership service wants to protect address changes. Supplied policy requires existing-account authentication, but many members cannot receive SMS. Frame alternate accessible verification and recovery requirements instead of declaring SMS mandatory or universally secure. Measure successful legitimate changes and support burden alongside unauthorized-change reports; do not claim a deployed solution or legal compliance.