Customer acceptance engine¶


ID	`MOD-153`
System	SD02
Repo	`bank-kyc`
Build status	Deployed
Deployed	Yes
Last commit	`a11935cd2c1c3a838cac1fe27f1f9cc6baa67e71`

Purpose¶

The customer acceptance engine is the formal gate that converts KYC verification status, CDD risk tier, fraud score, sanctions result, and product-specific criteria into an explicit, auditable accept/decline/refer decision before any product account or facility can be opened. It is the platform's implementation of the FATF customer acceptance programme — the point at which the institution formally decides to enter a business relationship. Every decision is recorded with full input snapshot and rule trace, satisfying the documentary requirements for AML examination.

What it does¶

Acceptance rule evaluation¶

Evaluates a structured rule set for each product application, in sequence: (1) identity verification — must be verified via MOD-009; (2) sanctions screening — must be clear via MOD-015; (3) PEP status — PEP flag triggers EDD requirement; (4) onboarding fraud score — above threshold triggers REFER; (5) CDD tier achieved vs. CDD level required for the product (from MOD-127); (6) customer risk score from MOD-039 for higher-risk products; (7) jurisdiction and product eligibility; (8) product suitability for retail credit products. Rule thresholds are deployment parameters — the rule structure is fixed.

Decision outcomes¶

ACCEPT — all rules passed; product onboarding proceeds
DECLINE — hard-fail rule triggered (sanctions hit, failed identity, jurisdiction ineligible); customer notified with reason code
REFER — soft-fail rule (high risk score, PEP requiring EDD, fraud score above threshold); case created in MOD-151 (Risk Case Console) for compliance officer review; product onboarding held
HOLD_FOR_EDD — PEP or high-risk customer where EDD not yet complete; gated on EDD completion event from MOD-010; no manual action required unless EDD SLA expires

Formal risk rating record¶

The acceptance decision is written to kyc.acceptance_decisions: customer_id, product_id, decision, decision_at, methodology_version, inputs (JSONB snapshot of all rule inputs), applied_rules, triggered_rules, reason_codes, and decision_officer (null for automated, officer_id for compliance overrides). This record satisfies AML-012's requirement for a documented, auditable customer risk rating with methodology reference.

Adverse action notices¶

For DECLINE outcomes on credit products, an adverse action notice is generated citing the specific reason code, satisfying NZ CCCFA and AU NCCP obligations on credit decline communication. Non-credit product declines generate a standard notification via MOD-063.

Re-evaluation triggers¶

When a customer's CDD tier changes, PEP status is updated, or a sanctions hit is resolved, active product relationships are automatically re-evaluated. If a re-evaluation produces a DECLINE for an existing product, a compliance officer case is created in MOD-151 rather than an automatic account closure.

Compliance reason¶

AML-011 requires a customer acceptance programme that determines who the institution will and will not accept. Without a platform-enforced gate, this programme exists only as a policy — individual operators may admit customers who should have been declined. AML-012 requires a formal risk rating with documented methodology; the acceptance record is that rating. FATF Recommendations 10 and 17 require customer acceptance decisions to be documented and auditable for correspondent and high-risk customer relationships.

Commercial reason¶

A formally documented acceptance decision with a complete input snapshot is a valuable risk management and legal asset if the relationship later becomes problematic. The absence of a documented acceptance decision — especially for a high-risk customer — is a significant liability in a regulatory examination or a legal dispute.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-009	eIDV & document verification	Required	—	eIDV result is a required acceptance input — acceptance cannot proceed without a verified identity on record.
MOD-010	CDD tier assignment engine	Required	—	CDD profile provides the risk tier, PEP status, sanctions status, and customer type that the acceptance rules evaluate.
MOD-013	Real-time sanctions screener	Required	—	Onboarding fraud score is a rule input — a score above the configured threshold triggers a REFER outcome.
MOD-015	False positive management	Required	—	Sanctions screening result must be clear before any acceptance decision can proceed to ACCEPT.
MOD-039	Customer risk score model	Optional	—	Customer risk score from the ML model enriches the rule evaluation for high-value or high-risk product types; not required for basic deposit account acceptance.
MOD-048	System decision log	Required	—	Every acceptance and decline decision is written as an immutable system decision log entry for AML and regulatory examination.
MOD-127	Product configuration panel	Required	—	Product configuration defines the minimum CDD level, suitability criteria, and acceptance parameters for each product type.
MOD-103	Neon database platform bootstrap	Required	—	Neon database and schema provisioned by MOD-103 must exist before this module can read or write Postgres.
MOD-104	AWS shared infrastructure bootstrap	Required	—	AWS shared infrastructure provisioned by MOD-104 is required before this module can be deployed.
MOD-151	Risk case console	Optional	—	FR-713 case creation for REFER and HOLD_FOR_EDD is event-driven — MOD-151 subscribes to bank.kyc.acceptance_decided; v1 satisfies FR-713 via SNS alert to MOD-076 and durable event on the bus.
MOD-063	Notification orchestration	Optional	—	FR-714 adverse action notice for credit product DECLINEs is event-driven — MOD-063 subscribes to bank.kyc.acceptance_decided filtered on DECLINE and product_category=CREDIT; v1 stub is SNS alert to MOD-076.

Required by¶

Module	Title	As	Contract
MOD-063	Notification orchestration	Optional enhancement	`contract/events/`

Policies satisfied¶

Policy	Title	Mode	How
AML-011	Customer Acceptance Policy	`GATE`	No product account or facility can be activated until the acceptance engine has produced a formal ACCEPT decision — the gate is enforced at the service layer with no bypass path.
AML-002	Customer Due Diligence (CDD) Policy	`GATE`	Acceptance enforces the CDD tier required for each product type — a customer who has not completed the required CDD level cannot be accepted regardless of KYC pass status.
AML-012	Customer Risk Rating Policy	`CALC`	The acceptance decision record IS the formal customer risk rating — it carries the input snapshot, methodology version, decision outcome, and tier assignment required for AML examination.
AML-004	Politically Exposed Persons (PEP) Policy	`GATE`	PEP status is an explicit rule input; a PEP customer cannot be accepted without EDD completion on record — the gate enforces this with no override path below the compliance officer role.
CON-006	Product suitability and governance	`GATE`	Product suitability is evaluated as part of acceptance for retail credit products — a customer whose profile falls outside the product suitability criteria is referred, not silently passed.

Capabilities satisfied¶

(No capabilities mapped)

Part of SD02 — Customer Identity & KYC Platform Compiled 2026-05-22 from source/entities/modules/MOD-153.yaml