Signatory rules define the authorisation requirements of each payment. Every payment has to be covered by a signatory rule to be able to be processed and sent to the bank.

Administrators can create, edit and delete rules in the Settings editor.

📘

In case the Tenant settings approval has been enabled, the experience is slightly different. Read more

⚠️

Signatory rules are critical for the functioning of the platform. In order to properly configure them, be advised to ask for guidance or training at [email protected]

Signatory rules

The signatory rule management provides the possibility to overview, consult, edit, audit or create new signatory rules. Signatory rules are crucial to the function of the LYNKS interface, in order to approve payments before instructing the bank to execute them. To not break the functionality, administrators should be confident in the management and understanding of the implications of possible modifications.

The signatory rules have multiple roles: on one hand they are validating the creation of payments according to the configured parameters, on the other hand they decide who is eligible to approve payments. The combined parameters of a signatory rule are applicable for creating and approving payments:

• Accounts - to which account or account group will this rule apply to.
• Ranges - from which minimum amount to which maximum amount will this signatory requirement apply to.
• Currency - which currencies are to be included in this signatory requirement.
• Payment category - which payment categories are to be included in this signatory requirement.
• Counterparties - payments towards which counterparties should follow this signatory requirements.
• Signature method - defines how payments will be approve, and by whom

On the payment creation, the interface validates if the chosen values are covered by a signatory rule, which will be applied on the that specific transaction. Once the transaction is created and waiting for signatures, the applied signatory rule provides a list of eligible signatories and the amount of required signatures to send the payment to the bank.

Manage signatory rules

The signatories can be removed and added, either by adding a user to a user group on the user management section or by adding them directly under the signatory rules. All parameters can be modified by administrators inside the LYNKS interface. The modifications should be done carefully as the impact can be critical on the functionality of the platform.

When requesting signatures, the selected signatories will be prompted with a signature request. The number of signatures per user group is the number of people that will need to sign the payment per selection.

Approval options

• Auto approve - payments falling under a rule with this approval option, will be automatically approved and will be sent to the bank.
• Auto reject - payments falling under a rule with this approval option, will be automatically rejected and will not be sent to the bank. Rejected payments can be re-triggered.
• Define signatories - the signatories and number of signatures a number of signatures can be required per payment meeting the rule’s parameters. The signature requirements can be defined as a combination between a number of required signatures from a selected combination of users and user groups. More than 1 signature can be required from this combination of users and user groups. Supplementary combinations of signatories and number of signature requirements can be added.

Download matrix

The download button, available on the top right corner of the signatory rules screen, is generating an extract of the currently configured settings as excel file. The file is a consolidated overview of the Access and permissions settings of the users and the configured signatory matrix.

The first sheet is a recap of the users permissions tied to the roles assigned to him.

The second sheet is a listing all of the configured signatory rules with their parameters and the eligible signatories.

Overlaps

Overlaps occur when there is more than one rule covering a scenario. Payments falling in an overlap will accumulate the signatory requirements of both rules, potentially causing a bottleneck.

Note: when overlapping rules have as outcome auto approve or auto reject, as well as signatures, the signatures will prevail.

The expandable rows are providing an overview of the rules that are overlapping to facilitate the handling of the overlaps. Administrators can edit the colliding rules, in order to remove the overlaps.

⚠️

Editing signatory rules to remove overlaps is a critical intervention in the behaviour of the interface.

Gaps

Gaps are combination of parameters that are not covered by any rule. A payment that falls in a gap will be automatically rejected as all payments need to be covered by a signatory rule. Identified gaps can be turned into new signatory rules directly by clicking on the '+' button in a gap.

⚠️

Payments not covered by any rule (gaps) will be automatically rejected.

Audit log

The audit log is keeping an audit trail of all the effected changes on the signatory rules. As usual the audit log is tracking the date of modification, the user and the modification: for instance the update of required signatures, parameters in a rule or the creation of a new rule.