FinCheqIQ

Acceptable use

What FinCheqIQ enforces, and what it records while you work. These rules are the same in every deployment because the platform implements them — they are not a summary of the bank's policy document.

The bank's acceptable-use policy is a legal document supplied at deployment, and it governs. This page states the platform's side of it: the behaviour FinCheqIQ makes impossible, and the behaviour it writes down.

Your account is yours alone

Accounts are provisioned by an administrator and activated with a bank-issued code. There is no self-service registration anywhere in the product, and no shared or team account: every action carries the identity that performed it into the audit trail, so a shared credential makes the record meaningless rather than merely untidy.

You act within your role

Least privilege is enforced by the platform, not by convention. Affordances your role cannot use are removed from the page rather than greyed out, and a blocked attempt is logged with your identity and the resource you tried to reach. Nothing about that is held against you — it is how least privilege is evidenced at audit.

You do not approve your own work

Maker-checker separation is structural. A decision you submit as maker cannot be approved by you as checker; a different authorised approver must agree before anything is released. The same rule governs configuration: a threshold, a limit, a role assignment or a reference signature always needs a second administrator.

Sensitive material is opened for a reason

Reference signatures and core banking credentials are masked by default. Revealing one is a deliberate action, and the access entry is written against your identity and cannot be edited or removed afterwards. Security Monitoring surfaces an unusual volume of reveals as an indicator — a pattern worth a person looking at, not a finding and not an accusation.

The record cannot be amended

The audit trail is append-only and hash-chained. It has no edit or delete affordance for any role, including administrators, because a record you can amend is not evidence. Removing or altering an entry breaks the chain visibly.

What the bank defines

These are policy rather than platform, and are supplied by the bank at deployment.

The policy text itself The wording staff accept at sign-in, and the sanctions for breaching it.
Session length and lockout thresholds How long a session lasts, and how many failed attempts lock an account.
Device and location rules Whether a bank-managed device in a controlled processing area is required.
Approval hierarchy and role names The roles shown in this prototype are the requirement-named ones, not a proposed bank org chart.
Back to sign in v1.0 · prototype