Compliance and governance guide

This guide explains the controls built into FlowSentry and how they support your institution's anti-money-laundering and counter-terrorist-financing (AML/CFT) obligations. It is written for MLROs, internal audit, administrators, senior management and evaluators who need to understand how decisions are governed and evidenced. It describes the product's controls at a high level; your institution remains responsible for its own compliance programme, policies and regulatory judgements.

1. Governance principles

1. Human accountable, AI accelerated. People make every decision with regulatory consequence. AI drafts; it never decides.
2. Four eyes on regulated outcomes. A second, different person approves every governed change and decision.
3. Fresh proof of identity for sensitive actions. Step-up asks for a second factor no more than five minutes old.
4. Evidence or it didn't happen. Every alert, score, hit, decision and AI draft carries the evidence behind it, attributed to a named person.
5. Configuration over code. Thresholds, lists, calendars, reason codes, risk models and policies are your institution's governed settings.
6. Least privilege. Roles grant only what a job needs; navigation and the server enforce the same permissions.

2. Maker-checker (segregation of duties)

FlowSentry enforces maker-checker on the server, per item. A person may hold both the maker and checker permission — an MLRO can record suspicion and decide on someone else's — but never checks their own item. An attempt is refused with "The approver must be a different person from the author (segregation of duties)."

Maker action	Checker action	Step-up for the checker
Record suspicion	MLRO decision: file, return or do not file	Yes (to file)
Close an alert	QA review of a sample of closures	No
Propose a true screening match (or a clear that policy routes to a checker)	Confirm or reject	Yes
Propose a watchlist version or entry	Activate	Yes
Propose a good-guy exclusion	Approve or reject	Yes
Author a monitoring rule version, or propose switching a built-in off	Approve or reject	Yes
Capture an onboarding application	Approve or decline	Yes, for high-risk
Review a high-risk onboarding application	Senior approval	Yes
Propose a KYC change on a live customer	Approve or reject	Yes
Propose a risk override or draft a risk model version	Approve or activate	Yes
Submit an EDD case	Approve the relationship or reject	—
Propose institution settings or a policy	Approve	Yes
Request a data source go-live	Approve go-live	Yes
Create a mapping template version	Activate	Yes
Prepare a CTR batch	Release	—

Pending items appear in the checker's My approvals inbox and notifications. Rejections require a reason, which the maker sees.

3. Step-up authentication

Multi-factor authentication is mandatory for MLROs, Deputy MLROs and administrators, and available to everyone through authenticator apps and passkeys. Step-up requires a fresh second factor immediately before sensitive actions — filing decisions, true-match confirmations, list and exclusion approvals, rule activation, KYC and risk approvals, high-risk onboarding approvals, settings approvals, kill switches, source go-lives and key rotation. It defends against an unattended session being used to approve a regulated outcome.

4. The audit trail

• Append-only and hash-chained. Each audited module writes to its own chain; every entry includes a hash of the previous one, so altering or deleting a past entry breaks the chain.
• Named people. Entries record the real user — never a generic "system" account for a user's action — with what changed, before and after, and when.
• Verified on view. The Audit trail page (/audit) re-verifies every module's chain each time it opens and shows Chain integrity.
• Wide coverage. Rule versions and approvals, screening decisions, list changes, KYC changes, risk scores and overrides, onboarding decisions, case actions, STR decisions, settings, kill switches, data sources and keys, mapping templates, document access, reveals of masked identifiers, exports and searches.

Auditors and administrators can read the audit trail; auditors can also read cases (including STR-restricted ones), rules and customers for independent testing, but cannot act on anything.

5. Explainability and reproducibility

Area	What an examiner can see
Alerts	The rule and version that fired, the window, each threshold against the actual value with exchange-rate provenance, and the trigger transactions
Rules	A plain-English description, every version with differences, who authored and approved each, backtests and performance
Screening	The subject and list entry side by side, attribute-by-attribute reading, score breakdown and the decision history by named user
Risk ratings	A factor-by-factor breakdown for every score, the model version used and the score history; scoring is deterministic for a given model version and customer snapshot, so a past score can be reproduced
Risk models	Versioned definitions with calibration rationale, maker-checker activation and a downloadable governance document pack
Decisions	Coded reasons and rationales for every disposition, the MLRO decision log and the internal no-file register

6. AI governance

• Drafts only. AI assistants summarise alerts, draft investigation memos and STR narratives, explain screening matches and risk ratings, review KYC changes and answer questions. They cannot close alerts, decide hits, file reports, approve changes, edit lists or activate rules.
• Labelled. Every output shows AI draft — advisory with a confidence, or Generated without AI when a rules-based draft is shown instead.
• Pseudonymised. Names, identifiers, phone numbers, account numbers and similar values are replaced by tokens before any model call and restored only on screen.
• Data stays where you decide. Institutions holding real client data use a self-hosted model tier, so client data does not leave your environment; cloud models are used only with synthetic data.
• Logged. Every model call is recorded with the feature, prompt version, model, tokens, cost, latency, outcome and the person who asked; what each person did with each draft — used, edited, added to notes or discarded — is recorded too. The AI usage dashboard summarises it.
• Switchable. An institution-wide AI features kill switch, plus per-assistant switches, turn AI off instantly; every assistant keeps working with a rules-based draft.
• Tested. Prompts are versioned and regression-tested against fixed cases before any prompt or model change.

7. Tipping-off controls

• STR material is visible only to STR-privileged roles (MLRO, Deputy MLRO and Auditor).
• A case becomes STR-restricted once an STR is involved.
• Relationship managers never see alerts or cases; they answer factual information requests only, and investigators are reminded never to mention suspicion.
• Executives see aggregate dashboards only.
• Exports and document views are watermarked with the viewer's name and audit-logged.

8. Data protection

• Tenant isolation: every record belongs to one institution and is filtered on every query.
• Masking: identifiers are masked in registers and exports; Reveal is recorded.
• Documents: scanned before use and encrypted at rest with a unique key per document.
• Logs: no personal data in application logs.
• Retention: a per-institution policy, defaulting to seven years; purges produce signed deletion certificates.

See the Security and privacy overview.

9. Regulatory alignment

FlowSentry is designed around the obligations of Kenyan reporting institutions and international standards. The table maps obligations to the product features that support them.

Obligation	Source	Supporting features
Monitor transactions and report suspicious transactions	Proceeds of Crime and Anti-Money Laundering Act (POCAMLA); AML Regulations 2013	Real-time monitoring rules and scenarios, case management, suspicion clock, MLRO decisions, goAML STR/SAR
Report cash transactions above the threshold	POCAMLA and FRC directives	Daily CTR batching with release by a second person
Terrorist financing controls and designated persons	Prevention of Terrorism Act 2012; UN Security Council resolutions	UN and Kenya domestic designation lists, priority handling of statutory hits, rescreening on designation, nil/positive certificates
Risk-based approach, CDD and EDD	CBK Prudential Guidelines on AML/CFT; FATF Recommendations 1 and 10	Customer risk rating, EWRA, onboarding with beneficial ownership, EDD workbench, periodic reviews
Politically exposed persons	FATF Recommendation 12	PEP screening, PEP register, floor rules, senior approval of high-risk relationships
Record keeping	POCAMLA; FATF Recommendation 11	Seven-year default retention, append-only audit trail, insert-only transaction records
Digital credit providers	CBK Digital Credit Providers Regulations 2022	Configurable thresholds and typologies for digital lending and mobile money
Data protection	Data Protection Act 2019	Minimisation, pseudonymisation for AI, access control, masking, retention and deletion certificates
Electronic reporting to the FIU	Financial Reporting Centre (FRC) goAML	goAML report generation, readiness checks, portal hand-off tracking, rejection handling

Note: Thresholds and deadlines are your institution's settings and must be set with your MLRO in line with current law and regulator guidance. FlowSentry ships sensible defaults, not legal advice.

10. Preparing for an examination

1. Run the Audit trail and confirm chain integrity.
2. Prepare a Regulator review sample with findings recorded by name.
3. Export the STR register and the no-file register for the period.
4. For each active rule, show the plain-English description, version history, approvals and backtest.
5. For the risk model, download the version's doc pack and show a sample of customer score breakdowns.
6. Show the AI usage dashboard and explain the AI controls above.
7. Show dashboards for SLA compliance, alert outcomes and filing timeliness.

Related

• MLRO guide
• User roles at a glance
• AI and data protection FAQ