How Ward decides

Ward is a decision model. It answers one narrow question per call (should this payment pass, is this name listed, is this applicant verified) and returns a typed answer: a decision, a score and the signals behind it. It does not write prose, browse on its own initiative or take actions. Your code decides what happens next.

Three outcomes

KYC answers use VERIFIED / REVIEW / DECLINED, mapped to the same three in the envelope.

What is inside

Each capability combines deterministic checks with learned components:

• Rules and matrices with published weights: every signal has a code, a weight and an explanation (for example STM_STRUCTURING, weight 0.55). Nothing is hidden behind one opaque number.
• Learned components: the column reader that understands any file layout, the Ask intent router, the card and contact-risk scorecards, and, per client, models trained on your own feedback.
• Reference data: official sanctions lists (OFAC, UN, UK, EU), PEP lists, regulatory enforcement, WMID (Ward Merchant Intelligence Data) and the typology catalog.

Every answer names the version of each component that produced it (components), so a decision can be reproduced and audited.

Principles

1. Fail closed. A list that was not loaded, a lookup that timed out or a field that could not be read is a reason to STEP_UP, never a silent pass. See Fail-closed handling.
2. Say what was not seen. needs lists the fields that would sharpen the answer; coverage says how much of the input Ward could read.
3. Advisory until proven. A model trained on your data runs in shadow, then as advice next to Ward's decision, and decides only after it beats the current champion on later cases and you approve it.
4. Input is data. Text inside an input (a memo line, a document, a web page) is never read as an instruction to Ward.

What Ward is not

Ward does not file reports with regulators, freeze accounts or contact customers. It gives the decision and the evidence; the obliged entity acts. See Evidence pack.