Administrator guide

This guide is for the administrators who set up and run FlowSentry for an institution. It covers institution settings, kill switches, webhooks and reason codes, monitoring rules and screening lists from an administrator's point of view, data integration, operational health and a go-live checklist. Integration engineers should also read the Integration guide.

1. What administrators can and cannot do

As Administrator you can:

• propose and approve institution settings (never your own proposal), turn kill switches and manage webhooks and reason codes;
• manage and approve data sources and mapping templates, and upload files;
• approve monitoring rule versions;
• propose changes to watchlists and exclusions (approval sits with list approvers);
• read the audit trail and regulator reviews, rules and dashboards, including AI usage;
• view Platform health.

You cannot work alerts or cases, see STR material, or approve your own changes. You need MFA: enrolment is mandatory for administrators, and most of your approvals need step-up.

Note: Plan for at least two administrators. Settings changes, source go-lives and mapping activations each need a second administrator to approve.

Users and roles

User accounts and role assignments are set up for your institution when it is provisioned. A self-service user and role screen is not yet available in the product; to add, change or remove a user, or to reset someone's MFA enrolment, contact your FlowSentry service contact. Enterprise single sign-on (for example Microsoft Entra ID, Okta or Google) can be arranged for production deployments.

Navigation follows roles automatically: granting a role makes its pages appear in the rail, flyouts and palette, with no further configuration.

2. The Administration hub

Administration (/admin) groups every page you can open:

Group	Pages
Institution	Tenant settings, FX rates
Data and integration	Data sources, Mapping studio, Load data, Ingestion runs
Governance	Audit trail, Regulator reviews
Platform operations	Platform health
Your account	Security & MFA, Passkeys

3. Tenant settings

Tenant settings (/admin/settings) has several sections.

Settings under maker-checker

The following change only through a proposal and a second administrator's approval with step-up:

• Base currency: the currency thresholds and dashboards are expressed in.
• Time zone: for example East Africa Time (Nairobi).
• Business calendar: Kenya public holidays or weekends only, plus Gazetted holidays you add.
• Suspicion clock (business days): how long the MLRO has to decide a recorded suspicion (1–30; platform default 2).
• Required KYC for individuals and for organisations: the items that decide whether a customer is Complete or Incomplete.

To change them:

1. Select Propose a change, edit the values and Submit for approval.
2. Another administrator opens the change from My approvals, reviews the differences and selects Approve (step-up) or Reject with a reason.
3. You can Withdraw your proposal until it is decided.

Platform defaults apply until a version is approved: KES, East Africa Time, the Kenyan calendar and a 2-business-day suspicion clock. Versions lists every proposal and its decision.

Kill switches

Kill switches turn a feature off for your institution at once:

Switch	What it controls
AI features	Investigation memos, narratives, explanations, Ask Sentry and other AI assistance
Client onboarding (CLM)	Onboarding applications, their checks and the core-banking hand-off
Identity verification	Document and liveness checks with the identity provider

Each change needs a reason and step-up and is audit-logged. With AI switched off, every assistant shows a rules-based draft instead, so work continues. See Manage tenant settings and kill switches.

Outbound webhooks

Register an endpoint to receive signed event notifications, for example when a metric breaches its red threshold. Each delivery carries a signature your receiver verifies with the subscription secret. Recent deliveries shows attempts and outcomes; failed deliveries retry with backoff and are eventually dead-lettered, and every attempt is audited.

Disposition reason codes

The reasons analysts pick when they close an alert. Add or reword a code or Deactivate one. Keep the list short and meaningful — reason codes drive the false-positive analysis on dashboards.

4. FX rates

FX rates (/admin/fx) holds the exchange rates used to normalise amounts into your base currency. A rule whose threshold is in a currency with no rate in force cannot evaluate, and file analysis flags FX gaps. Keep rates current.

5. Monitoring rules

• The engine runs FlowSentry's built-in scenario pack merged with your institution's active rules. A tuned built-in keeps its id and replaces the built-in for your institution only.
• The Rule library (/monitoring/rules) lists everything that can raise an alert, with status, severity, typology and recent alert counts.
• Rules are authored by analysts and the MLRO with the guided builder. As administrator you can approve versions: open the rule from My approvals, read it in plain English, check the backtest and Approve (step-up) or Reject with a reason. You cannot approve a version you authored.
• A built-in can be switched off and switched back on through the same approval.
• Before approving, check the backtest's projected alerts and estimated false positives, and ask whether the thresholds are parameters rather than fixed numbers.

6. Screening lists

• Watchlists (/screening/lists) shows each list's source, active version, record count, publication date and freshness. Platform lists (UN Security Council, OFAC SDN, Kenya domestic designations and a PEP list) are maintained by the FlowSentry list desk.
• Statutory lists are always screened. You may unsubscribe from a policy list with a reason and step-up; it is audited.
• A source file that fails validation — schema changes, a large drop in records, an older publication date — is quarantined and never screened; Platform health shows the alert.
• Internal lists (for example exited customers) and the provisional list for urgent designations are yours: a list manager proposes entries and a different approver activates them with step-up. Activation rescreens your book. No other institution screens against your internal lists.
• The Four-eyes policy (/screening/policy) sets which clears need a checker, the QA sampling rate for single-person clears and the clear memory. It changes under maker-checker with step-up.

7. Data and integration

• Data sources (/integration/sources): connect each system; every source has its own signing key, starts in testing and goes live only after a second person approves with step-up.
• Mapping studio (/ingestion/mapping-studio): map source fields to FlowSentry's canonical model; templates are activated under maker-checker.
• Load data (/integration/files) and Ingestion runs (/integration/runs): file runs with control totals, duplicates and quarantined rows.

As administrator you approve go-lives and template activations that integration engineers request. See the Integration guide.

8. Operations and health

Platform health (/ops/health) is your single pane:

• Scheduled jobs: the latest run and any failures in the last 24 hours.
• Ingestion sources: freshness and lag against each source's silence SLA.
• Webhooks: pending, delivered and dead-lettered deliveries.
• Platform sanctions and PEP lists: when each was last fetched.
• AI usage: calls, tokens and cost.

Scheduled jobs — list refreshes, rescreening, risk backfills, dashboard read-model rebuilds and daily CTR batching — run in the background. Running a job on demand or disabling one is done by the platform operator in the Ops console, with step-up; ask your FlowSentry service contact if you need a job run now. See Check platform health and scheduled jobs.

9. Governance and audit

• Audit trail (/audit): recent governed actions — when, module, entity, action and the named principal — and Chain integrity, which re-verifies every module's hash chain each time the page opens.
• Regulator reviews (/regulator/reviews): sample reviews for examiners, with findings recorded by name.
• AI usage dashboard (/dashboards/ai): calls, spend and latency by feature and model.

10. Data protection and retention

• Each institution has a retention policy; the default is seven years, in line with record-keeping obligations. Purges produce signed deletion certificates.
• Identifiers are masked by default; reveals and exports are audit-logged.
• Documents are scanned and encrypted at rest.
• No personal data is written to application logs.

See Security and privacy overview.

11. Go-live checklist

1. Confirm institution settings: base currency, time zone, calendar, suspicion clock, required KYC — approved by a second administrator.
2. Review reason codes and the alert-work policy (SLA windows, QA sampling, bulk-close scenarios).
3. Load FX rates for every currency you transact in.
4. Connect data sources, approve their mapping templates and go-lives, and run a reconciled first load.
5. Confirm watchlists are fresh and your internal lists are active.
6. Review the built-in scenarios with the MLRO: backtest, tune thresholds, switch off any that do not apply.
7. Activate a calibrated risk model (or accept the platform reference model as an interim, documented decision).
8. Confirm every user has the right roles and that MLROs and administrators have enrolled MFA.
9. Decide the AI features switch with the MLRO and your data protection officer.
10. Check Platform health is green and walk one alert through to closure end to end.

Related

• Administrator and integration engineer
• Compliance and governance guide
• Troubleshooting FAQ