> For the complete documentation index, see [llms.txt](https://docs.editran.onesait.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.editran.onesait.com/documentacion-editran/publico-editranff-lite-v7-open-en/windows/administradorff/aplicaciones-para-verificar-firmas/reglas-de-firmado.md).

# Signing rules

A signing rule is the set of parameters that defines the criterion or set of conditions under which the files to which it applies must have been signed. For example:

* Transfer files with payer NIF 00000000T and operation amount greater than up to 10,000 require one signature and it must correspond to one of the certificates in the Treasurers group.
* Transfer files with payer NIF 00000000T and operation amount greater than up to 100,000 require two signatures and these must correspond to one of the certificates in the Treasurers group and one of the certificates in the Auditors group.
* Files for direct debits with a total amount up to 100,000 must have been signed by at least two groups out of the three defined: Level\_One\_Authorized\_Representatives, Level\_Two\_Authorized\_Representatives, and Level\_Three\_Authorized\_Representatives. Each of those groups has a defined minimum number of signatures and is made up of authorized representatives of the corresponding level.
* Files to/from Iberpay must be signed with a single certificate, either of the two that make up a group that will have been defined with the value 1 in the Required number of signatures parameter.

When no signing rule is defined in an application, the signatures received will be validated against their structure, consistency of the signed data, and expiry of the certificates used, but no additional validation can be performed, such as checking that the required number of signatures has been reached, the suitability of the specific identities of the certificates used for signing, that each certificate has only signed amounts for which it is authorized, etc.

When signing rules are defined according to the content of the file (approval check), the signatures will be validated with the most restrictive one among all those that apply, understanding as the most restrictive the one with the most rule, NIF, and suffix parameters defined. For example, an application has three signing rules: one for the Transfers rule (34) and payer NIF 00000000T, another for the Transfers rule (34), and another with no rule.

Case 1) The application receives a file with the Transfers rule and payer NIF 00000000T. Any of the three signing rules could apply to the file, but the signatures will be validated with the first one because it is the most restrictive of the three.

Case 2) The application receives a file with the Transfers rule and a payer NIF different from 00000000T. In this case, the second and third rules could apply to the file, but the signed file will be validated with the second one because it is the most restrictive of the two.

Case 3) The application receives a file with the Direct Debits rule (19). In this case, only the rule with no rule defined applies to the file, and it will be validated with that one.

If an application has signing rules defined and none of them apply to the received signatures, the verification process will end with an error.

When the button *View rules* is clicked in an application, the view of signing rules associated with that application is displayed. When the button ![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/XrHm7ZqLXVyeWKhVNDOn/image1.png) is clicked, a new rule is added, in which the following parameters can be configured:

![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/in8xa6WsOOjq3tUviBem/image2.png)

* **Rule:** format that the signed files to which the rule being defined will apply must have. The options are 34 (Transfers), 19 (Direct Debits), or No rule. When Transfers or Direct Debits is specified, additional validations can be performed according to the content of those files (NIF, Suffix, and Total Amount or Largest operation amount). The No rule option is appropriate when you do not want to define a signing rule based on that data but independently of it.
* **NIF (only with rule 34 or 19):** the one corresponding to the main party (payer or creditor) of the files for which the rule is being defined. This is optional.
* **Suffix (only with rule 34 or 19 and if a NIF value has been specified):** the one corresponding to the main party (payer or creditor) of the files for which the rule is being defined. This is optional.
* **Required signatures:** the minimum number of signatures that the file must include.
* **Required groups:** the minimum number of groups whose conditions must have been met.

When you click on a rule, the list of users and groups associated with that rule is shown at the bottom.

![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/JtXPVNZEtF6Hwjz0kgmQ/image3.png)

Initially, the list of users associated with the rule is shown and, when you click the button ![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/AM0TmEawFwfZmN4tcnH4/image4.png) , the list of groups or signer groupings is shown. Clicking ![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/9neJQG467KIjvAA3jxZq/image5.png) , returns to the list of users again.

When you click on ![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/2swGoeqW13ugJs6Vnl2t/image6.png) in the list of users, a new row is added to the list, in which the following fields must be filled in:

* **User:** combo box used to select the remote user associated with the application.
* **Group (optional):** combo box used to select the group to which the user will be associated. It shows the groups that have been previously created by clicking ![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/bBUflSuDSfTMHhswqjrF/image7.png) .
* **Required signature:** if checked, it indicates that the user's signature must always be included. If it is not present or is not valid, the rule will count as not fulfilled if it is a user acting outside a group and, if it is a group user, the group will count as not fulfilled.
* **Amount type (only with rule 34 or 19, optional):** if you want to establish an amount limit that the user can sign, one of the two criteria must be selected: largest amount or total amount.
* **Amount (only with rule 34 or 19, optional):** if you want to establish an amount limit that the user can sign, the maximum value should be entered here. If a file with a higher amount signed by this user is received, the signature will be considered invalid.
* **Countersigner (optional):** counter-signature is the signature of another signature and always occurs after one or more signers have signed the document. This parameter will indicate, if applicable, the remote user who must have signed the signature of the user or users who signed the entire document. If this parameter is set and a signed file is received in which the counter-signer has not acted, the signature will be considered invalid.

The same user cannot be both signer and counter-signer at the same time in the same rule. However, it is allowed for a user to be a counter-signer for several users.

![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/7zyVtlzH0qEprnjfZKjU/image8.png)

When you click on ![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/6fYBgGg4SkmbX8SBBolH/image9.png) in the list of groups, a new group is added in which the following fields are defined:

* **Name:** the name of the group. It must be unique within the same rule.
* **Required number of signatures:** the minimum number of signatures from users associated with the group that must be present or valid.
* **Mandatory:** if this parameter is checked, the group must reach the required number of signatures for the rule to be considered fulfilled.

![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/mOmmDAfXza2uGrvG0CG7/image10.png)

In a rule, a signer can only participate individually or as part of groups, but not in both ways simultaneously.

To delete users or groups, select the user or group in question and click the button ![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/KAw7ia8eE9rS71BaIntd/image11.png) . **For applications with Iberpay, a single group will be configured with one mandatory signature, and two users or certificates must be associated with it.**

Finally, when the button *Save all* ![](https://content.gitbook.com/content/04WMoASrRViaNE1vVCAL/blobs/GVsUG9YE36xBJpO9Yf4w/image12.png) at the top, the information will be stored in the system. If there is any problem, an informational message with the cause will appear.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.editran.onesait.com/documentacion-editran/publico-editranff-lite-v7-open-en/windows/administradorff/aplicaciones-para-verificar-firmas/reglas-de-firmado.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
