The answers provided for the different items that make up a questionnaire are validated in run time against the definition of the properties associated to the KYC items. If, for example, a property has been configured to have an edit-validate rule, the associated validation logic is executed during the data capture process to ensure that the value is according to expectations. In the same manner, if another property is configured as a date, the system ensures that its value has the right format and it represents a valid date.

This validation mechanism is simple from an implementation perspective, but it might fall short when some more complex validations are required. For those scenarios, there are a couple of extension points that can be overwritten to include that advanced logic that cannot be easily configured at property or item level. The two extension points are invoked as part of the ValidateItemResponses data transform, which in turn is invoked when the case is submitted for approval in the ProcessKYCCase process flow.

The nature of the validations that can be implemented in the following rules varies:

• Although data captured within a KYC Type is expected to be independent of data captured in other KYC Types, there may be situations where complex cross-validations are needed. Cross-validation may involve validating responses against data captured in other KYC Types or data captured and stored in a Master Profile.
• Validation of responses captured or modified against external systems. Data retrieved from an external system could have changed between the time it was retrieved and the time responses are submitted. This can include retrieval of such data and validation to ensure that data is in sync with the external data source.
• Validation of responses against data captured or modified at the case level. In certain situations, you might want to ensure that the data captured in the questionnaires somehow aligns with the data available at the case.

• Defining KYC Types