Managing signatory jobs and exclusions in Electra

23/11/2015 printable version

The Electra user access rights management system was extended with another important function in Version 7 and now the system also takes into account the exclusions associated with various signatory jobs. This novel feature of the Electra system allows defining signatories' rights in an even more accurate manner.

Electra's point-based access rights system had already provided a highly flexible method for specifying whether a given user has the right to submit orders with respect to specific accounts, and if he does, how 'strong' that right is as expressed in a point value. This system also allows the management of co-signatories, e.g. primary signatories can be assigned 8 points and secondary signatories 2 points, thus ensuring that both signatories are needed to produce the 10 points required (by default) for submitting an order.

There is but a single thing that cannot be specified using this scoring system: situations where two or more users are not allowed to sign an order together. The operation of local governments provides a real-life example for this. There, the mayor and the notary are not allowed to sign orders jointly, even though they are primary signatories in their own right, who can co-sign orders with other users.

The management of jobs and mutually exclusive jobs implemented in Electra provides a solution to this problem.

Basic concepts

The jobs and exclusions system is implemented only for customers requesting it. This means that these functions are implemented in a transparent way and customers and users can carry out their jobs as usual, without any changes.

The use of jobs and exclusions must be individually set up for those customers who want to use this function. The settings can be specified by bank administrators via the WebAdmin interface.

They need to specify the jobs used by the customer and to set up the exclusion matrix based on them.


Customers can define their jobs individually and without any constraints. They can have any names, which can then be used as reference to the given jobs. (Different customers can have different names for the jobs in their hierarchy.) Names like 'notary', 'financial head' or 'assistant' are good choices for jobs. A job is simply a label which can be associated with the customer's users. The job name does not carry or grant any additional rights or possibilities in itself.

The administrator must first register the set of jobs (labels) used at and specified by the given customer. Then each user of the customer must be assigned a job from this set. Any single user can have only one job assigned to them. Both the job set and the job assigned to a given user can be modified later on (e.g. when a user is promoted).

A minimum of two jobs must be defined for each customer for the use of the exclusion matrix to make any sense. There is no upper limit to the number of jobs but, obviously, using too many jobs will make administration more complicated.

The jobs used by a customer can be managed via the WebAdmin interface:



Exclusions can be defined by completing a matrix. The matrix is used to specify that users doing a specific job are not allowed to jointly sign orders with users doing another specific job. For instance, if a local government specifies 'mayor' and 'notary' as jobs, they can also define that users in these two jobs are not allowed to sign orders together, which means that Electra will not accept orders signed by only the mayor and the notary.

The exclusion matrix can be defined by the bank administrator, using the customer modification function. Thus, a customer's jobs and exclusion matrix need to be defined according to its needs only once, by using the customer modification function. From that time on, whenever there is a change in the customer's users (new users join the customer, or existing users leave), the job sets and the exclusion matrix do not have to be modified, and only the appropriate jobs must be set for the new users. (E.g. when a new notary is employed, it is enough to specify that he/she is a notary, and the exclusion system will automatically manage his/her actions according to the settings.) This way, this 'job label' makes the bank's job much easier.

The system also allows specifying that two users doing the same job are not allowed to jointly sign orders. It means that customers can use settings where two financial heads are not allowed to jointly sign orders and can specify that such transactions should also require the signature of a user in a different job (e.g. that of a controller).

There is a new, simple interface for specifying exclusions and assigning user jobs, where all jobs, the exclusion matrix, and the job associations for each user of the customer can be set up using the following screen:

Following the selection of any two users, the WebAdmin interface will highlight the selected jobs in the matrix, giving visual feedback on whether the two selected users are allowed to jointly sign orders:

Signature evaluation

The evaluation of exclusion settings is independent from accounts, account rights and points.

When the Electra server receives a signed package and there are jobs specified for the given customer, the Electra server will check the signatories and their jobs. It will use the exclusion matrix to identify users not allowed to sign jointly, and will ignore these signatories in the later phases of the process.

After evaluating the exclusions, the server checks the account rights and signature points of the remaining signatories using the well-known standard procedure. If the remaining users have sufficient signatory points, the system will accept the package. If not, the system will decline it.

So, the evaluation of exclusions is independent from checking account rights and calculating signatory points, and is carried out before them.

For customers where no jobs, and therefore, no exclusions are specified, this processing step is skipped, and the system only evaluates the account rights and signatory points using the usual method.

 Related news:Related articles