Control who can access your lending operation — and what they can do.

One control center for staff access and security

Access control is part of financial control. From one place an administrator sees who has access, which grants are waiting for approval, which devices are trusted, and what happened today — the live state of the controls, not a policy document filed away.

From an access spreadsheet to one record

Drag the slider: the same staff access, kept in a spreadsheet versus kept in Ustawi.

The Ustawi access model

Access in Ustawi is built up in layers. An identity is given a role; the role carries capabilities; the account operates within an access scope; sign-in is tied to a trusted device; every action runs through those checks; and the result is written to the audit trail. Each layer is a control, and together they are how access maps to what a person can actually do.

Identity → Role → Capability → Scope → Device → Action → Audit

Sensitive access is a formal request

Sensitive grants are not handed out in a conversation. Each is a formal request with its own reference, sitting in a pending-approval queue for a reviewer to approve or reject — so a grant has an owner, a reason and a record.

Maker-checker on sensitive grants

No one grants themselves a sensitive permission. One person requests the change (the maker); a different person reviews and approves it (the checker); the capability activates only on approval; and the decision is recorded. Self-approval is prevented — a maker cannot be their own checker.

Self-approval is prevented by the system.

Protect sensitive actions, not just pages

Access control is applied to what an account does, not only what it can open. The sensitive actions in a lending operation each sit behind their own control.

Trusted device management

Staff and field agents sign in from enrolled, approved devices. An administrator sees the trusted devices, approves pending enrolments, and can revoke a device's trust — so device access is managed, not assumed.

Field agent device trust, connected to the app

A field agent cannot authenticate from just any device. The device is enrolled, an administrator approves it, and only then is it a trusted device able to sign in — and that same trust is what lets the field agent app run its worklist, collections and receipts.

What happens when a device is lost?

A lost phone is handled as a controlled sequence, not a scramble. Trust is revoked, sign-in from that device stops, the revocation is recorded, and a replacement device is enrolled and approved.

Revocation and re-enrolment are the real behaviors.

A full audit log

Important actions are recorded — including failed and rejected attempts. Each event carries the actor, the action, the target, the access before and after, the result, and IP, device and session metadata, so an administrator or auditor can review what happened and follow it up.

One staff member, one complete access history

An administrator can open a single account and see its own activity — access changes, device enrolment, logins and the actions taken — in one timeline.

One access-control backbone across the platform

Staff Admin & Security is not a page other apps link to — it is the access-control backbone every other app enforces against. The same identity, capabilities, scope, device trust and audit trail apply wherever a staff member acts.

The AML connection

Sensitive compliance work needs the right people to have the right access — and a record of who did what. Access to AML cases runs through the same capabilities and audit trail, which is how Ustawi underpins the tipping-off controls in the AML app.

Who uses it

Access administration is a shared responsibility. Each role gets the view and the outcome it needs.