Governance & Audit — Compliance as a Partnership

The compliance partnership model

Compliance is not a department you ask permission from. They're a partner who, if engaged correctly, gives you a wider operating envelope than you'd get by asking permission per-decision.

Concrete operating patterns:

• Named Compliance counterpart per platform initiative — not "the team," a person.
• Weekly or biweekly standing meeting — kept even when there's nothing burning. Relationship maintenance pays interest.
• Compliance on the design-review distribution — not just pre-launch sign-off. Earlier they see, less they push back later.
• Joint OKRs where it makes sense — e.g. "time-to-policy-change in production." Aligns velocity incentives.
• Compliance-friendly tooling — the platform exposes interfaces Compliance can use (policy doc editor, audit search, manual-review console) so they don't have to file tickets to do their job.

AML risk assessment alignment

Every regulated entity maintains an AML risk assessment — a formal document that scores risk across customer types, products, geographies, and channels. It's the policy backbone for everything downstream: KYC tiering, EDD triggers, transaction-monitoring rules, training, board reporting.

What this means for the platform:

• Your tier system should map to the risk assessment's customer-risk tiers, not be parallel to them.
• Geographic risk ratings in the assessment drive which jurisdictional policy applies and how strict the screening is.
• Product risk ratings drive which products require EDD / which tier upgrade.
• When the assessment is updated (annually, or when triggers fire), the platform should be able to reflect the change without a code release.

You don't write the risk assessment. You make sure the platform is the operational expression of it.

Regulatory examiner readiness

Regulators audit. Sometimes scheduled, sometimes not. The platform's defensibility shows in the audit. Things examiners typically ask, and what the platform should produce on demand:

Every one of these should be a query, not a project. If reconstructing it requires a 2-week eng investigation, you're not audit-ready.

Change control on onboarding flows

Onboarding flow changes are often material under regulation. Some require regulator notification; some require board-level review. The platform must support this without becoming sclerotic.

A workable change-control model:

1. Classify the change. Cosmetic (copy tweak), operational (vendor swap), policy-affecting (different consent capture), or material (new tier definition).
2. Map class to gate. Cosmetic → PM approval; operational → Eng + PM; policy-affecting → Compliance sign-off in the PR; material → Compliance + Legal + sometimes regulator notice.
3. Make the gate enforceable. CI checks that the right approvers signed. No back doors.
4. Log every change with classification, approvers, effective-date, rationale. This log is auditable.
5. Allow emergency override with explicit role permission and post-hoc review.

Audit trail of policy decisions

Every decision the platform makes must be reconstructable. Two layers:

• Per-applicant decision audit — full chain of evidence, signals, policy version, decision, actor.
• Policy-level audit — every change to a policy with approver, rationale, effective dates.

The audit trail is immutable, append-only, encrypted, and retained per the strictest applicable retention (often 5-7 years post-account-closure). PII may need to be tokenized or encrypted with per-applicant keys to balance audit retention with privacy obligations.

Worth knowing the vocabulary: WORM (Write-Once-Read-Many) storage, chain of custody, tamper-evident logs (signed or hash-chained), legal hold (retention extends beyond normal window when litigation is anticipated).

Periodic re-KYC strategy

KYC is not "verify once." Risk changes. Customers' profiles drift. Regulators expect periodic refresh, typically:

• Low risk: every 3-5 years, or trigger-based.
• Medium risk: every 1-2 years.
• High risk (PEPs, high-volume, certain industries): annually, sometimes more frequently.
• Event-triggered: a new sanctions hit, a profile change, a transaction-monitoring alert, a regulatory inquiry.

Platform implications:

• Every applicant has a next_review_at date driven by risk tier.
• Re-KYC is a flow primitive — typically lighter-weight than initial KYC, but with explicit reverify-this-thing semantics.
• User experience for re-KYC is a product question — interrupt them at login? Soft-block specific actions? Communicate via email? Compliance + Growth co-own this.
• Non-response handling: if a customer doesn't complete re-KYC by deadline, what's the soft-block / hard-block ladder?

Sanctions re-screening cadence

Sanctions lists update; PEPs become PEPs after onboarding; adverse media surfaces. The platform must re-screen continuously.

• Sanctions: typically daily. Some firms do real-time on list update.
• PEP: typically monthly or quarterly.
• Adverse media: often weekly; depends on vendor capability.
• Wallet screening (crypto): per-transaction at the perimeter; periodic refresh on counterparty addresses.

New hits on existing customers generate alerts to ops; the platform's job is the queue infrastructure and the dispositioning record. Disposition outcomes feed back into the customer's risk profile.

The three lines of defense

Vocabulary every regulated-fintech PM should know cold. The three-lines-of-defense model:

The platform sits within first-line operations but is the system second-line uses to do their job. Being able to say "the platform gives second-line independent query access to the audit log" is a sophisticated answer.

What good governance looks like — a checklist

• Named Compliance counterpart per major initiative; standing meetings.
• Policy documents are data, versioned, signed-off, with effective-dates.
• Change classification with enforced approval gates in CI.
• Every applicant decision is reconstructable from the audit log.
• Re-KYC and re-screening schedules per risk tier, with operational queues.
• Compliance has self-serve tooling for policy edits, audit search, and ops oversight.
• Regulator-readiness drills: at least annually, simulate an examiner request and time the response.
• Postmortem reviews include a compliance dimension — was there a notification trigger?
• Training and access controls — only authorized roles can change policy or override decisions, and every override is logged.