Governance Overview

Organisations necessarily have a need to control the access that their staff have to certain software applications.  The reasons for this range from regulatory requirements, to business controls, to defining staff roles, to simple good practice.  As with any enterprise software, Duco has built-in functionality that allows organisations to define appropriate levels of access for their staff based off individual business requirements.  For example, you can define groups of users that can:

• Add and remove other users
• Create and configure new processes
• Only run existing processes

Duco Governance Tools

In Duco there are several layers at which governance controls can be applied. These are broadly broken down into:

• Global roles
• Process permissions
• Reference data permissions

Each layer offers further degrees of granularity that allow clients to implement a governance model which provides the best fit for their organisation.

Global Administrative Roles

Duco offers a global layer of governance, constituting administrative Roles that are associated with one or more tasks users may perform. It should be noted that these rights are system-wide. The following roles are available:

  

 

Groups

Groups are a mechanism for bundling together both global roles and also users.

For a global role to be permissioned to a user account requires two steps. First, the role must be added to a Group. Next, the Group must then be associated with a user account to confer the functionality.

So for example, if you wanted to grant someone the Process creator role, you would first need to add it to an existing Group, let's say called 'Reconciliation Builders'. To then grant a user access to this role, we would then need to add the 'Reconciliation Group' to their account.

Groups may also simply be used as groupings of users, with no associated roles. For example, you can have a group called "London FX team" that contained all members of a particular team, but had no global roles permissioned to it. The purpose of a Group like this would be ease of administration. At the process level, access to a reconciliation can be granted to individual Users and/or Groups. So it is often easier to create various Groups of users, and then permission these Groups to the appropriate processes.

Users can be members of multiple Groups.   

Groups are very useful, it is usually easier to manage permissions on the basis of groups rather than individual users. Exactly how many groups of users you will need depends on how your organisation is structured and also its size.

Group Segregation

This section explains how one could organise Duco users into groups according to the teams and departments within an organisation.

There are two main reasons to divide users into groups:

1. They allow different departments within the organisation to manage their users independent of one another. For example, the London Fixed Income team will want to manage its processes and users independently from the New York Equities team.
2. Groups are a tool that can be used to meet regulatory requirements around segregation of duties and to respect “Chinese walls” within the organisation.

Example: A user should not be able to both manage user permissions and also investigate breaks. Otherwise the user could accept a break without performing the necessary investigation.

Example: “Chinese walls” might dictate that someone who deals with more technical aspects of the Duco configuration (such as setting up users and groups, automatic file uploads, etc.) should not be able to see financial data and client details.

Furthermore, Groups grant a user only the level of access to the system necessary for them to perform their assigned duties. This is a leading practice from both a security and an audit perspective.

Organisation & Management-level Control

This document assumes the sample organisational structure shown in the diagram below. The diagram also shows how the organisational units are associated with the Duco User Groups.

The organisation may be divided into several departments (e.g., Europe, North America, APAC, etc. or fixed income, equities, derivatives, etc.), with one or more teams within each department.  Department boundaries are typically based on geography, function, or product lines.

User Account Management

For the entire organisation, there is a single “User Account Management” group, which is responsible for the creation/deletion of users and for addition/removal of users from user groups across all departments (these users may also serve as Group Managers*). It is important to make sure that there are at least two administrators in this group, in case one leaves or becomes locked out. Importantly, members of this group are not granted access to the actual Processes (reconciliations). This means they do not have visibility to match results, content of reference data tables, the matching rules for a process and, in general, any financial data. 

*Group Management

It may be desirable to have a segregated responsibility exclusively for Group management. This involves responsibility for creating new Groups, and assigning the relevant global roles to those Groups. Assignment of the Group to an individual User would still sit with the User Account Management.

Super Users

There are multiple “Super User” permission groups, with one group for each department. This group is responsible for controlling labels, and assigning and controlling access for “SMEs” during process creation.

Team-level Permissioning

Within each department, there may be multiple reconciliation teams. Each team might be responsible for a set of reconciliation processes (i.e. setup and maintain the processes, check results and investigate breaks). The diagram below shows the relationship that might exist between team members and user groups.

The manager for a team is part of the “Super Users” group for their department.

There is one “SMEs” user group for each team. A team member is designated as SME and becomes part of the “SMEs” group for their department on an as-needed basis (i.e. when a process needs to be created or updated).

There is one “BAU Solvers” user group for each team. A BAU solver is a team member who can take action on breaks that belong to this group. Actions include accept/close breaks, attach labels to a results items, etc.

* Note that roles that allow to close, force-close, manually match and allocate the exceptions were moved to the process permissions level.

Finally, there is one “BAU Analysts” user group for each team. A BAU Analyst is a team member who checks results and investigates breaks, but is not allowed to take action on them.

The following table gives a brief description for each group and shows which roles are associated with each group in the model described earlier in this document:

* These permissions may or may not be desirable for you BAU Solver, depending on the Exceptions workflow your organisation follows. In case of need, these permissions can be granted to every process separately.

Related documentation

• Users, groups, roles and permissions
• Adding a user
• Adding a group of users

High-level Process Flows

User Creation and Deletion

This section documents the user creation and deletion processes. It is a more detailed description of the first swimlane “User Account Management” in the diagram in the previous section.

User Creation

User Account Management: The group of users responsible for adding/removing users, and assigning them to groups if desired. This is documented in the section “User groups and roles”.

The Team Management: The manager or supervisor of a reconciliation team. This is normally one person. The Team manager is also a member of the “Super Users” group, as the figure in the section “User groups and roles” shows.

When a new Duco user is needed, do as follows:

• Team Management: A new Duco user is required. TM request the creation of a new Duco user via the organisation’s issue tracking system.
• TM: Adds to the request details necessary for the creation of the user: E.g., Username, email, business line, etc.
• User Account Management: Receive new user request.
• TM: Add and setup the user the user as requested.
• TM: Confirm that the user can log in and has the correct level of access.
  - User confirms that they are able to log in.
  - TM updates ticket in issue tracking system.

Audit

Audit Point (external): The user creation request should be traceable (e.g., the ticket number in the issue tracking system used to raise the request). The ticket should also contain confirmation that the user was created and that they are able to log in.

Audit Point (Duco): Entries in the Duco Audit log give evidence that the user was created. See image below:

To access the Audit log:

• Click on three-lines menu at the top right of the screen and select Administration.
• Click on Audit log.
• Click on Export to download the audit log in Excel format.

User Deletion (suspension)

This section documents the process to follow when a user no longer needs access to Duco. Typically this happens when the user moves to a different team within the organisation or when the user leaves the organisation. As the title shows, the user account is not actually deleted, but only suspended.

If users access Duco via Web SSO. User deletion or suspension will be handled externally from Duco.

“User Account Management” and “Team Management” are already described in the previous section.

When a user no longer needs access to Duco, do as follows:

• Team Management: A Duco user no longer needs access to Duco.
• TM: Request the suspension of the user via the organisation’s issue tracking system.
• User Account Management: From the “Manage users” screen, set the user as “suspended”.
• UAM: Notify GM that user is suspended.

Audit

Audit Point (external): The user suspension request should be traceable, e.g the ticket number in the issue tracking system used to raise the request. The ticket should also contain confirmation that the user was suspended.

Audit Point (Duco): An entry in the Duco Audit log gives evidence that the user was suspended. See image below.

To access the Audit log:

• Click on three-lines menu at the top right of the screen and select Administration.
• Click on Audit log.
• Click on Export to download the audit log in Excel format.

New process creation

This section describes what to do when a new reconciliation, or, in Duco parlance, a new matching process, needs to be set up.

When a new process is required, do as follows:

• Team Management: Designates one user within the Team as the SME for the process.
• Team Management: Request via the organisation’s issue tracking system to add the user to the “SME” group.
• Super users: Assigns the relevant person to the “SME” group.
• Super users: Confirm that user was added to the group (update ticket)
• SME: Create the process using process code and name according to naming conventions.
• SME: Load initial data inputs
• SME: Add “Super users” group as Config admin for the process.
   - From the process main screen, click on “Settings” → “Permissions”
   - In the “Groups” section of the “Permissions settings” screen, add the group “Super Users”
   - Select “Config admin” as the level of permission for the group.

• SME - Configure process: Set up initial matching rules and iteratively update the configuration of the process until it produces the desired results.
• SME: Lock configuration. I.e., enable change control.
   - Go to “Settings” → “Change control”
   - Tick “Change control enabled”

• Super users - Review process/Authorise:
   - Review the changes to the process configuration
   - Another Config admin for the process needs to approve the change request.

• Super users - Remove user from “SME” group.
• SME - User removal confirmed

Audit

Audit Point (external): Process creation request should be traceable. E.g., the ticket number in the issue tracking system used to raise the request. The ticket should mention the name of the person assigned as the SME and the name of the process to be created.

Audit Point (Duco): The Audit log should contain entries:

• When the Super users add the user to the “SME” group (first image below).
• When the SME user created the processes (second image below).
  
  
  
  

Export process configuration in PDF

As part of system governance and auditing process, you may want to make a record of the reconciliation process configurations and share this with your auditors. You can do this by exporting the configuration details into PDF. For generic two-sided processes you can choose to export the configurations used in a specific run.  For cash reconciliations, it will always export the configurations used for the latest submission.  

Change management

It is sometimes necessary to update the configuration for a process in “production”. I.e., a process that is fully configured and run on a BAU basis. There are many reasons why a process configuration needs to be updated. These are some examples:

• The format of one of the data sources has changed. It contains new fields, date formats have changed, etc.
• The data contains new types or records. E.g., When the process was set up the a data sources contained only Futures, now they contain also Options. The process configuration could be updated to filter out the Options. Or perhaps the matching rules should be updated to also handle Options.
• Reference data needs to be updated. Matching rules often user reference data tables to lookup and transform parti IDs, product codes, and other reference data. This data often needs to be updated.

This change management flow enables users to update a process configuration in a controlled and auditable way. This is a variation of the “New process creation” flow described previously in this document.

When an existing matching process needs to be updated, do as follows:

• Team Management: Designates one user within the Team as the SME for the process.
• Team Management: Request via the organisation’s issue tracking system to add the user to the “SMEs” group.
• Super users: Assigns the relevant person to the “SMEs” group.
• Super users: Confirm that user was added to the group (update ticket)
• SME: Create a staging copy
   -  From the process main screen, click on “Staging”
   -  Click on “Create Copy”

• SME - Update process configuration: Iteratively update the configuration of the process until it produces the desired results.
• SME - Raise change request:
   - From the process main screen, click on “Staging”
   - Click on “Raise change request”

• Super users - Review process/Authorise:
   - Review the changes to the process configuration
   - Another Config admin for the process needs to approve the change request.

• Super users - Remove user from “SMEs” group.
• SME - User removal confirmed

Match result analysis and resolution

This is the business-as-usual (BAU) process of analysis and resolution of match results.

BAU Analysts: As mentioned also in the section “User groups and roles”, a BAU analyst is a member of the reconciliation team who checks results and investigates exceptions, but is not allowed to take actions on them.

BAU Solvers: As mentioned also in the section “User groups and roles”, a BAU solver, on the basis of the analysis performed by a BAU analyst, takes action on an exception. For example, contact a counterparty to check why the exception happened, contact an internal team to fix a data feed, etc. The BAU solver also takes workflow actions within Duco. E.g., apply labels, close/accept exception, etc.

In more detail, the process is as follows:

• The process runs and new results are available. This normally happen after an automatic file upload, but in some cases, it may happen after a manual file upload via the UI.
• BAU Analyst - Check integrity of rules: The BAU analyst performs an integrity integrity check to verify that the data submission happened as expected. For example:
   - Is the data from the expected time period? For example, the previous business day.
   - Is the data volume as expected? E.g., If the submitted data normally contains 10,000 records, a submission with only 100 records is suspicious.
   - Does the data contains an unusually high number of exceptions? This could indicate that the wrong data was submitted, or that the process set up needs to be updated. For example, by adding a filter rule or updating a reference data table.

• BAU Analyst - Analyse exceptions: Investigate why the exception is happening.
   - For an unmatched item, why there is not a matching item in the other data set?
   - For a partially matched item: Why are some fields not matching?
   - If necessary, contact other parties, e.g. the data provider, to identify the root cause of the break.
   - In the comments, document the cause of the exception and suggest a resolution action.

• BAU Analyst - Assign to BAU solver. Assign exception to BAU solver.
• BAU Solver - Receive exception: Perform initial check of exception.
   - Is the exception assigned to the correct person? If not, reassign to the BAU Analyst or to the correct BAU solver.
   - Decide priority. E.g., handle immediately, before end of day, within 3 days, etc.

• BAU Solver - Review comments:
• BAU Solver - Handle break resolution:
   - If the resolution is straightforward and no further analysis is necessary, leave a short comment (E.g.: “Resolved as suggested”) and resolve the exception as the BAU analyst suggests in the comments.
   - If further analysis is necessary and it can be performed by the BAU analyst, leave a comment that explains what the BAU analyst should do and assign to the BAU analyst.
   - If further analysis is necessary, carry out the analysis and do what necessary to resolve the exception. For example this could include:
  • Speak to data provider
  • Contact counterparty
  • Make sure data is entered or corrected manually

Take the appropriate workflow action. E.g.: Apply labels, Accept, Close, etc. These actions are specific to each matching process and therefore outside the scope of this document.

• BAU Solver - Add action description in comment: Add a description of the action taken to resolve the break. For example:
• Amended data manually on system X.
• Update reference data table, in following runs this exception should not occur.
• Technology team fixed the issue in the data feed, in following runs this exception should not occur.
• BAU Solver - Confirm match in next process run: In next process run, confirm that the same exception has not occurred again.

Configuring auto-log out and password renewal

Auto logout setting

The automatic logout after inactivity timeout setting is configurable. Set the logout for your Duco environment to any time required by your security team, to gain better control.

Password renewal

Duco users should be reminded to never share their password with anyone in or outside of the organization. Some organizations have stringent user management policy that requires users to update their Duco passwords regularly (e.g. every 3 months). In addition to integrating your identity management system with Duco through single-sign-on (SSO) to have your password policy managed centrally, you now have a new option by asking us to configure an expiration period for you.

The expiration period is set in a number of months. Every time a user resets his/her password, it will expire automatically after the specified period. The next time he/she logs in to Duco, it will prompt him/her to set a new password. So together with this enhancement, you can also specify how many old passwords are not allowed to be reused. 

Reach out to your Customer Success Manager to learn more about how we can configure auto logout and password renewal settings that best support you.