What is a validation rule?
A validation rule is a check of data in relation to other data in a message. If a single attribute needs to meet certain conditions (e.g. a minimum or a maximum value), a check on the schema is sufficient. But sometimes the value of an attribute depends on the value of one or more other attributes, as shown in the examples below. Conditions like these involve more than one attribute and can be checked with a validation rule.
Example 1
In case of a coverage for third party liability of a motorvehicle, an insurer can determine that a surplus to the premium is applicable, if the regular driver is under 24.
Example 2
In case of vehicle hull coverage, an insurer can determine that, if the insured sum is higher than 40.000, the deductible amount should be higher than 500.
Technical use validation rules
Every financial product or service contains a set of rules, applied to the data elements associated with the product or process. The AFD-definition Standard provides a framework and tooling to record specifications and checks, as well as checks at data element level. Validation rules in the AFD-definition Standard make use of XPath (AFD 1.0) and JMESPath (AFD 2.0) to ensure that a financial product is put into production accurately and efficiently.
Parties that have set up their own business rules engine environments, can convert validation rules to their own environment.
XPath (AFD 1.0)
XPath (XML Path Language) is a query language designed for navigating and selecting data from XML documents. It is developed by the World Wide Web Consortium (W3C) and provides a standardized way to traverse the hierarchical structure of XML and locate specific elements and attributes. XPath expressions can be employed to pinpoint and extract data from XML documents, facilitating the processing and handling of XML-based information.
W3C Reference: [XPath 3.1](https://www.w3.org/TR/xpath-31/)
XPath plays a crucial role in XML-related technologies, such as XSLT (Extensible Stylesheet Language Transformations) and XQuery, enabling precise and efficient extraction of data from XML documents.
Modeling validation rules with XPath uses a subset of the capabilities of XPath functions. The AFD-definition Standard is based on XPath 2.0. The use of XPath within the AFD- definition Standard focuses primarily on registering dependencies between two or more pieces of data in an AFD XML message.
Ready-made libraries
The XPath specification is implemented in a lot of languages: for example Python or .Net Framework. A list of possible XPath-implementations can be found here: https://en.wikipedia.org/wiki/XPath, header ‘Implementations’.
Testing XPath expressions
To make sure the validation rules themselves are correct, it is recommended to use an expression tester. Some examples of XPath testers:
Validation rules within the AFD-definition Standard
XPath can be employed to establish unambiguous specifications, allowing for the examination of dependencies between multiple data elements within a single AFD message or database. Within the AFD-definition Standard, the XPath or JMESPath expression must always take the form of a conditional expression, yielding either a ‘true’ or ‘false’ result.
A validation rule within the AFD-definition Standard is constructed as follows:
- Namespaces: references to other locations
- A commonFunctional entity with the identifying characteristics of the document
- The actual AFD validation rules
An example of of a validation rule is available in XML Examples (XPath).
The actual validation rule contains the following elements:
- id: an element containing a rule ID of the validation rule.
- test: the validation rule written as an XPath (AFD 1.0) expression.
- message: an element containing the error message to be displayed in case the executed rule returns a ‘false’.
- source: an element containing documentation on the validation rule.
The validation rules within the AFD-definition Standard appear as a conditional expression:
if (‘logical expression’ then ‘logical expression’ else true())
Validation rules in XPath (AFD 1.0)
When utilizing XPath to model validation rules, a subset of XPath functions’ capabilities are employed. The AFD-definition Standard is built upon XPath 2.0. XPath’s usage within the AFD-definition Standard primarily centers on capturing dependencies between two or more data elements within an AFD XML message.
The validation rules for AFD 1.0 can be found in afdXPath.Library.xml. A validation rule (in XPath) contains the following elements:
- rule id: XML element containing a rule ID of the AFD 1.0 validation rule and the XPath-expression
- message: an optional element containing the error message to be displayed if the rule executed returns a Boolean false
- source: an optional XML-element containing a reference to documentation on the validation rule
- databinding: an optional repeating XML-element to include AFD 1.0-attributes appearing in the XPath-expression
All elements described above, are present in the example below.
<rule id="Rule_02" test="if (xs:decimal(//CA_VERZSOM) gt 40000) then xs:decimal(//CA_ERB) gt 500 else true()">
<message>The deductible amount for vehicle hull coverage should be higher than 500, if the insured amount exceeds 40.000.</message>
<source>Product specifications hull coverage motorvehicle</source>
<databinding>CA_VERZSOM</databinding>
<databinding>CA_ERB</databinding>
</rule>
SIVI defined guidelines for the composition of AFD 1.0 validation rules. These rules are shown in the overview below.
Main validation rules
Name | Description |
Conditional expression | A validation rule should always be a conditional expression (yielding either ‘true’ or ‘false’) |
After ‘if’ | The condition that should be met to execute a validation within the XML-message. In the example above that is ‘CA_VERZSOM > 40000’. It is possible to use an array of XPath operators, to refer to multiple attributes. Example: if (xs:decimal(//CA_VERZSOM) gt 50000 and xs:string(//CA_GEBIED) eq E) then xs:decimal(//CA_ERB) gt 1000 else true() |
After ‘then’ | This expression contains the validation that should be executed, if the earlier if-condition is met. In the example above that earlier condition is ‘ERB > 500’. It is possible to use an array of operators and refer to multiple attributes. Example: if (xs:string(//CA_GEBIED) eq ‘E’) then (xs:decimal(//CA_VERZSOM) gt 30000 and xs:decimal(//CA_ERB) gt 1000) else true() |
After ‘else’ | The logical expression on the right side of the ‘else’ clause becomes active when the ‘if’ condition required to execute the validation rule is not satisfied. In other words, there is no justification to proceed with the execution of this validation rule (the ‘then’ clause). In the validation of XPath within AFD 1.0, the ‘else’ clause is consistently populated with ‘true()’. Consequently, this XPath rule remains ineffective if the validation conditions are not fulfilled. |
Additional AFD validation rules
Name | Description |
Comparisons to XPath | In general, the XPath function FN:DOC allows referencing to nodes from another XML message and comparing the values of these nodes. An AFD validation rule however, is executed solely within the context of a single AFD 1.0 XML message. So within the AFD-definition Standard it is prohibited to compare elements from different XML messages. |
Chaining of output | Validation checks that utilize the result of validation rule 1 as the input for validation rule 2 are not permitted. In simpler terms, chaining of AFD 1.0 validation rules is prohibited. This restriction is in place to prevent negative impacts on processing speed and to simplify the troubleshooting process.. |
Custom functions | While it is technically feasible to incorporate programming languages beyond the W3C XML standard into custom functions, formatting an expression mandates the exclusive use of XPath 2.0 expressions, without integrating other programming languages. This requirement is essential to prevent users from encountering obstacles within the application aspect of the Standard AFD-definition when utilizing XPath expressions containing other programming languages. If necessary, a custom function can be requested from SIVI. SIVI can then subsequently integrate the expression into the AFD XPath Library, making it accessible to all market partiesI. |
Arithmetic operators | Arithmetic operators should be defined ‘escaped’ in an AFD 1.0 validation rule. This precautionary measure is necessary to prevent misinterpretation by application components that support XML techniques, such as the use of ‘>=’. Below is a table outlining how such arithmetic operators can be escaped. |
Use of arithmetic operators in XPath
Arithmetic operator | Operator AFD 1.0 XPath |
> | gt |
< | lt |
>= | ge |
<= | ie |
= | eq |
!= | ne |
Examples of validation rules in AFD 1.0
Description | AFD 1.0 Validation rule |
If attribute A then attribute B If the sum insured is greater than 100000, then the deductible amount should be greater than 500. |
if (xs:decimal//CA_VERZSOM gt 1000000) then (xs:decimal//CA_ERB gt 500) else true() |
If attribute A and B then attribute C If the sum insured is greater than 50000 and the coverage area code is equal to ‘E’, then the deductible amount should be greater than 1000. |
if (xs:decimal//CA_VERZSOM gt 50000 and xs:string//CA_GEBIED eq ‘E’) then (xs:decimal// CA_ERB gt 1000) else true() |
If attribute A then attribute B and C If the coverage area code is equal to ‘E’ then the sum insured should be greater than 30000 and the deductible amount should be greater than 1000 |
if (xs:string//CA_GEBIED eq ‘E’) then (xs:decimal//CA_VERZSOM gt 30000 and xs:decimal//CA_ERB gt 1000) else true() |
If entity A exists then entity B should exist. If a policyholder entity exists, then a premium payer entity should exist. |
if (fn:exists(//PP/VP)) then fn:exists(//PP/PB) else true() |
If entity A exists then entity B should not exist. If a mortgage entity exists, then a lease entity should not exist. |
if (fn:exists(//HP)) then fn:not(fn:exists(//LC)) else true() |
Post your comment on this topic.