Segregation of Duties

Overview

Segregation of duties is critical to effective internal control because it reduces the risk of mistakes and inappropriate actions.  It helps fight fraud by discouraging collusion.

In the system, the segregation of duties requires that the user who creates or amends a record is different to the user who authorizes new or amended records, i.e. users may be assigned access to create or amend an applicable record but not to authorize it, whilst other users may be assigned access to authorise new or amended records.

Segregation of duties applies across all processes.

Segregation of duties in the system

Segregation of duties is applied in the system as follows:

- Changes that are done on global investment mediums.

- The same user cannot capture and authorize rules.

- The same user may not calculate and authorize remittance.

- The same user may not select and authorize income batches.

- The same user may not provisionally authorize Section 13A Interest and perform the final authorize of the transactions.

- The same user may not capture and edit, change or delete preference claims.

- The same user may not authorize a claim if they have been involved in the processing or amendment of the details of that claim.  (For more information refer to Benefit payment process section below).

- The same user who captures a switch may not override the fee.

- The same user who captures a switch may not submit/confirm a switch.

- The same user who captures bonus rates may not authorize the bonus rate.

- The Scheduler may not be the authorizer in any annuity process.

- Annuitant details may not be changed by the same user

- In the Bank Reconciliation Process, the user that processes the bank reconciliation may not manually match transactions if the document numbers are not the same

- The Scheduler of Expense Billing may not authorize the Expense Billing.

- The Scheduler of Benefit Statements may not authorize the Benefit Statements.

- The Scheduler of web reports may not authorize the reports for the Employer to view.

- The Team that grants functional security access to the menu items may not be the same Team that grants data level security to the schemes / products / projects / departments.

Processes

In the processes listed below, users are assigned access to create or amend an applicable record but not to authorize it and other users are assigned access to authorize new or amended records:

- Investment Medium *

- Scheme Update

- Income Batch

- Income

- Prior Claims

- Expense Billing

- Bulk Switching

- Bonus Rates

- Annuities

- Benefit Statements

- Member Investment Values

- Trustee Reports

* In the case of Investment Mediums access is only given to certain users and no authorization function is required.

Benefit payment process

If a change is made to any information for a claim, then those users involved in the processing or amendment of the details of the claim may not authorise that claim.

Whenever the User ID field is updated on any of the records used in the Benefit Payment Process, the system will update the User ID on the Ben Claim Auth record with a value for Claim User Type of DOER.

Authorise Claim

When a Benefit Payment is authorised, the system will read the Ben Claim Auth record with a Claim User Type of DOER and if the User ID of the user authorising the Benefit Payment is equal to any of the User ID’s found, the following error message will be displayed: 

            Authoriser cannot be the same as doer.

Where second authoriser is required, the same validation will be applied.

When a claim is authorised, the system will update the Ben Claim Auth record with a Claim User Type of AUTHORISER.

When a claim requires multiple authorisers, the system will read the Ben Claim Auth record with a value for Claim User Type of AUTHORISER or null to determine the User ID of the previous authoriser(s).

When extracting the data for the JU4BN Benefit Authorisation Users screen, the system will read the Ben Claim Auth records with a value for Claim User Type of AUTHORISER or for which the value is null.

Segregation of duties not applied

Segregation of duties is not applied in the following Processes as described below:

Authorization on remittance

For the authorization of a remittance, the Payroll already allows for more than one user to authorize and if more than one is required then a second authorizer has to be a different user.  This can be set up under Pay Centre Settings in Payroll.  This role can be added to users that will have the authorization function.

Bank reconciliation

For authorization on the matching of document numbers that are not the same – currently the bank reconciliation automatically matches transactions where the document numbers and amounts are the same.  The document number cannot be overwritten for transactions where the payment types are EFT or Cheque.  If the document number for transactions other than EFT or Cheque payments cannot be updated via the Manual Matching Process the following needs to be done where the amounts of the transactions are the same but the document number differs:

- If the document number is incorrect on the Cash Book (Ledger) transaction, the incorrect transaction must be reversed using the incorrect document number so that these transactions can automatically match in the Bank Reconciliation Process.  A new Manual Accounting Journal must be processed with the correct document number (i.e. the same number as used on the Bank Statement transaction), so that this transaction can be automatically matched to the Bank Statement item.

- If the document number is incorrect, the reconciliation must be closed and the Bank Statement item edited and then the Bank Reconciliation processed again.

This adds a lot of extra effort to the Bank Reconciliation Process and effectively makes the Manual Matching Process obsolete.  This together with the fact that the Bank Statement item can be edited without authorization and that there is a low risk related to the override of the document number for non-payment items is the main reason why Segregation of duties is not applied.

Access on the Conversion Tool

Currently any user has access to upload files via this Upload Process, but the intention is to restrict this access.

Transaction Codes have been added to the menu items on the Conversion Tool.  One Transaction Template can be created for the Transaction Codes to be linked to.  This Template can be associated or removed from a specific User Group.

Create a new Template Conversion on the EA827 Template List screen and link all transaction codes for file upload to this Template.

Transaction Action Codes

The following Transaction Codes have been added to the following menu items:

For a full list of all Transaction Action Codes refer to

Supplements

Transaction Action Codes

Transaction Action Codes