Teams For Shared Ownership
Group your users into teams, each with a name, a description and an active or inactive status, and use them for shared ownership and assignment across OneView workflows.
Organise teams, require independent approval, review who holds which access, and keep dated records of the decisions your programme depends on.
Teams give shared work a clear home without handing out permissions by accident.
Group your users into teams, each with a name, a description and an active or inactive status, and use them for shared ownership and assignment across OneView workflows.
Being in a team does not grant permissions. Roles decide what a person can see and change, and teams describe which operational group they work in, so ownership and authority stay separate.
Each membership records when a person joined, who added them, when it ended and who removed them. Teams with history are deactivated rather than removed.
Every case has one individual assignee, and when a team is set the assignee must be an active member. Each change of team or person asks for a reason and is recorded in the case history and the activity log.
Decide where a second pair of eyes is required, and configure it once in settings instead of relying on habit.
Switch on independent approval so work on a case is checked by a second person, and require approval before a case can be closed.
Set service level policies, due-soon warnings and the retention period that applies to your cases, from the same settings page.
Turn on review and approval for regulatory reports, choose how many levels of approval you need, up to ten, and name who can approve each level.
Name an approver and a review frequency for your Transaction Monitoring thresholds, and confirm each review when it is done so the due date moves forward.
Check at regular intervals that each person still needs the access they hold, and keep a record that you did.
Set how often access must be reviewed and see when the next review is due.
Starting a review lists the people involved, with the permissions each one holds, searchable in a single drawer.
Conflicts between duties are shown alongside each person, so combinations that should not sit together are easy to spot.
Record whether each person's access is still right. The review closes once everyone has a decision, and it can be exported as a CSV.
Where two or more people can run reviews, nobody decides their own access, so another reviewer has to.
Past reviews stay listed and filterable by status, so you can show when access was last checked and by whom.
Recovery targets, validations and review dates are recorded by your own people, so your institution can show what it decided and when.
Record your institution's own recovery time objective and recovery point objective, each with an approver, an approval date and a review date. Every update creates a new permanent version, so you can see which target was in force at any point in time.
Where the AI module is in use, record a yearly validation of the areas the AI acts on, entered by an independent person, with the earlier validations kept alongside.
Governance fields on thresholds and policies show who the approver is and when the next review is due. Where automated routing is used, a sampling rate sends a share of its decisions to a person for spot-checking, and each confirmed review is kept in a history, so accountability is visible where the setting lives.
See how teams, approvals, access reviews and recorded decisions fit together, and how they give your AML programme clear ownership.