KYRA:Complete User Guide

Bolstered by an agentic offering, autocompletion of tasks represents a huge step forward towards straight-through-processing within the application. Based on feedback from our clients, we have noticed a trend whereby Data, Documents and Related Parties Tasks would have been fulfilled in an initial onboard, and are then brought into scope again in the context of a Review or Maintenance Journey. A User would be forced to re-complete these Tasks without providing any value, as everything required of them had already been fulfilled. Taking this away, we came to the conclusion that if a User has already satisfied all outstanding validation in a previous Journey, we should not force them to re-complete a Task where they are not adding value.

Taking this insight away, we have now introduced a new functionality whereby if all outstanding validation is satisfied within a task, the Task can self-complete without requiring any User action. This is a capability that is opt-in at an individual Task level, allowing for greater flexibility.

This functionality is available for the following Task Types:

• Data
• Documents
• Documents V2
• Related Parties
• Data & Documents
• Related Party Data & Documents
• Blocking

Autocompletion Logic

The logic for a Task completing will be based on the validations configured in the Tenant's Policy. The Policy Requirements configured are validated as a Task enters a "preprocessing" status. Here, we validate if all validation is satisfied - with the most common and straight-forward example being if a Policy Requirement is "Mandatory" or not. For "Data" Tasks, we also check any validation configured against the requirements in a Task, to ensure that all existing data provided still meets the configuration provided. For example, if a "Date of Incorporation" field had "No Past Dates" validation configured, and the provided value for this field was in the past, the Data task would not autocomplete.

In simple terms, the grounds for closing a task via the Autocompletion Agent are the same as what a User would experience navigating a Task. If a User could simply hit "Complete" without any validation errors, the system will do the same.

There are some unique scenarios where Autocompletion will not occur:

Document Tasks

For Document Tasks – those being "Documents V1", "Documents V2" and "Data & Documents" specifically - the Autocompletion Logic looks specifically for mandatory document requirements that have an Approved status. If Document Persistence is enabled, the system will move any Document Requirements with a status of "Pending Approval" to a status of "Approved" as a part of this process. If all mandatory Document Requirements have a status of "Approved" and have at least one Document linked against them, the Task will autocomplete.

At this time, "Waived" and "Deferred" Document Requirements will not be eligible for autocompletion. Tasks where there are mandatory Document Requirements with either of these statuses must be manually completed by a User.

Related Party Task

The Related Party Task can be seen to have three types of requirements:

1. Add X Number of a certain Relationship Type
2. Add All Relationship Types
3. ID&V X Relationship Type

For Autocompletion, we can handle this first type of requirement, where we validate specifically the existing Related Parties and assess if the specified number of Relationship Types has been added. This is the only type of requirement that will allow for Autocompletion across multiple Journeys for the same Entity.

For the "Add All" type of requirement, this will always be required to completed by a User. This is because the determination that "All" of a given Relationship Type have been added is not something the application can confirm. It must be a User attestation that they have added all of the required Relationship Type, according to their best judgement. This means that if there is an outstanding, mandatory "Add All" requirement, this will prevent Autocompletion of a Related Parties Task. It is worth noting that once this requirement is satisfied within a Journey, any further interactions (via reopening the task for example) will be eligible for Autocompletion, as that requirement is now satisfied.

For "ID&V" requirements, we currently do not persist ID&V status across multiple Journeys. Like the above, the "ID&V" requirement must be confirmed and completed by a User manually. If there is a mandatory "ID&V" requirement that is not satisfied, the Related Party Task will be prevented from autocompleting. However, much like the above, if the "ID&V" requirement is satisfied within the same Journey, and then that Task is interacted again, the Task is now eligible for autocompletion because the mandatory requirement was dealt with prior in the Journey.

Related Party Data & Documents Task

When configuring the Related Party Data & Documents task in Journey Builder, the Automation tab is available in the task configuration panel. As with other tasks, this tab contains three configuration options:

1. Manual Completion
2. System Autocompletion
3. Conditional System Autocompletion

When System Autocompletion or Conditional System Autocompletion is enabled (and for the latter, the associated condition is met), the task applies a two-step evaluation, that aligns to the active task functionality, to determine whether it can autocomplete.

info

In some tenants, this feature may be referred to as the Autocompletion Agent or just simply Autocompletion. Both terms refer to the same functionality and capabilities. If you are interested to learn more about our agentic capabilities, please see the Fenergo Digital Agents section for more information.

Configuring KYRA:Complete

When Users navigate to the Journey Builder, they will see a new tab visible in the Task Properties for the seven tasks mentioned in this user guide. This new tab will be titled "Autocompletion Agent". In here a new dropdown will be seen titled “Completion Logic”. This dropdown determines the logic under which this Task can be autocompleted. These options are:

Manual Completion:

• This is the default option for all eligible Tasks (i.e., the seven tasks mentioned in this user guide). This simply means that this specific Task will always be completed by a User.

Agent Autocompletion:

• This option means that the Agent will always attempt to autocomplete this Task.
• As a reminder, the Agent will only complete a Task if all of the configuration in your Policy has been satisfied within that Task instance.

Conditional Agent Autocompletion:

• This option expands upon “Agent Autocompletion” and introduces a conditionality to the functionality. With this option, Clients can dictate that the Autocompletion logic should only be evaluated, if an associated Condition is met. This acts as a layer of protection when implementing autocompletion in your Journeys.
• With “Conditional Agent Autocompletion”, you can specify that a Task may attempt to be autocompleted by the application, but only if their “Risk Level” is “Low” and “KYC Level” is “Simplified".
• This condition can be thought of as an eligibility check to assess if the Task should be evaluated for autocompletion. If the condition is not satisfied, then the application will not attempt to autocomplete the Task. Even if the condition is satisfied, all validation within your Policy Requirements must still pass for the application to autocomplete the Task.

It is worth noting that this autocompletion behaviour is configured against each Task individually. Therefore, a client could configure autocompletion only in their “Periodic Review” Journeys if so desired, offering full flexibility to implement this functionality in the circumstances that meet your needs.

Finally, a common use-case for why something may be autocompleted is if a given Data Point has or has not changed during a Journey. For example, a Data Task that is focussed on capturing Screening Results may only need to be completed by a User, if those results have changed within the context of the Journey. To achieve this, a client can utilise our Current Entity Changes data source, which has been bolstered with a new operator of “Is Not Changed”. This will allow a Client to configure autocompletion conditionality that meets the previously mentioned use-case, like the below:

Referral / Reopen Logic for Autocompletion

One of the major use-cases we sought to address with this feature was the elimination of a very common frustration when completing Journeys. In a standard sequential Journey, when a User reopens a Task, they reopen all Tasks in between where they were in the Journey, to where they wish to reopen. This compounds the problem of Users having to manually complete or recomplete the same Tasks to get back to their original point in the Journey.

With autocompletion, before a Task becomes “in progress”, we re-evaluate its autocompletion logic. This means that if configured in your Journey, a Task may be forcibly user-completed the first time, and then the Agent can autocomplete the tasks each subsequent time upon a referral in the Journey. This means that Users are no longer forced to manually recomplete these Tasks, where they are adding nothing of value, and instead can focus on the items most needing their attention.

One important note on this referral / reopen capability with regards to Autocompletion, is that reopening a Task with autocompletion enabled will bypass that Task’s autocompletion check on a one-time basis. This is to prevent a scenario where a User attempts to reopen a Task and the Task immediately self-completes. The reopening of a Task will always be a specific action by a User, for a specific purpose. With this logic, this means that Users will be able to reopen the specific Task and make their changes as needed. It is important to note here however that any Tasks indirectly reopened will be reevaluated for autocompletion.

This ultimately means that a User could reopen a specific Task, make their changes, and then all Tasks in between will self-complete – resulting in the User returning to where they were in the Journey as soon as possible. This behaviour of course would only be applicable to those Tasks supporting this functionality. In other words, a configurator is required to ensure that that the individual Task[s] are set up for autocompletion using the "Agent Autocomplete" or "Conditional Agent Autocomplete" options as described above within the Journey Schema.

Audit

When a Task is completed by the Agent, the User will be able to be aware of this from the Audit Drawer of a Journey. The “AutocompleteStatus” represents the Agent’s attempt to complete the Task, and can vary from:

• In Progress: a temporal state while the Task is being evaluated
• Skipped: meaning the Task did not satisfy its associated autocompletion condition (if configured as “Conditional Agent Autocompletion”), or if there was outstanding validation preventing the completion of the Task
• Completed: the autocompletion completed successfully

Depending on if Agents are enabled on a tenant or not, the “CompletedBy” property will either be shown as “Autocompletion Agent” or as "System" which combined with “AutocompleteStatus” = “Completed”, can aid a User in both the Audit Drawer and in Advanced Reporting as to which Tasks were successfully autocompleted.

Configuring Automation for the OGS Unsubscribe Task

Applies to: Journey Builder administrators configuring offboarding journeys

Overview

The OGS: Unsubscribe from Ongoing Screening task supports automated completion to reduce manual analyst effort during client offboarding. You configure automation behaviour per-journey in Journey Builder using the Automation tab on the task.

Before you begin

• You must have Journey Builder configuration access.
• Automation affects all runs of the journey once saved. Test in a non-production environment before enabling in production.

Step 1 — Open the task settings

1. In Journey Builder, open the offboarding journey you want to configure.
2. Locate the OGS: Unsubscribe from Ongoing Screening task.
3. Click the task to open its settings panel.
4. Select the Automation tab.

Step 2 — Set the Completion Logic

In the Completion Logic dropdown, choose one of the following options:

Manual completion (default) The task behaves as it always has — a user must review and submit the unsubscription manually. Choose this if you want no change to existing behaviour.

System autocompletion The system runs pre-processing logic automatically when the task is triggered. Eligible entities and RPs are unsubscribed without user intervention, and the task closes automatically. Any entities or RPs that are not eligible (e.g. active for multiple clients, or clients in their own right) are marked accordingly but do not block task completion.

Conditional system autocompletion As above, but autocompletion only triggers when a configured condition is met. Use this option for journeys where you want automation to apply selectively.

Step 3 — Save the journey

Save and publish the journey as normal. The updated Completion Logic will apply to all subsequent runs.

Understanding the automated unsubscription logic

When System autocompletion or Conditional system autocompletion is active, the system evaluates each entity and RP in the task and determines the appropriate outcome:

Entity / RP type	Automated action
Main entity — not linked to other entities	Unsubscribed automatically
RP — not a client in their own right, not active for multiple clients	Unsubscribed automatically
RP — client in their own right	Marked Active for multiple clients, subscription retained
RP — linked to more than one entity	Marked Active for multiple clients, subscription retained

Once pre-processing is complete, the task closes without requiring user input. If the automation service fails, the task will surface for manual intervention in the usual way.

Task status during processing

When autocompletion is in progress, the task displays:

• An animated spinner in place of the status icon
• Grey styling to indicate the task is temporarily non-interactive

The task updates automatically once processing is complete.

Important Notes

• The logic underpinning why a Task is autocompleted comes directly from the Policy Configuration of your Tenant. If all validation is passed – including mandatory requirements – the Task will autocomplete.
• Autocompletion for these Task Types is supported in Portal. It is not supported in Salesforce currently.
• Autocompletion is evaluated during the “Preprocessing” status. If the Task autocompletes, it will never appear on a Dashboard for a User to pick up. If the Task cannot be completed, it will enter the standard "In Progress" status (represented by the blue icon). It is only then will a User be made aware via Notifications or their Dashboard, that this item requires their attention.
• Certain system auto tasks – for example Initiate Screening, Verify Entity, and Verify Associations – will display a "Task Started" event in the Journey. For these Task types, the status moves straight to autocompletion as no evaluation of requirements is carried out.
• Where a Task could otherwise be completed by a human but is autocompleted by the Autocompletion Agent (such as Policy Tasks), the Agent evaluates the Task's requirements and, if all validations pass, moves it directly from "Pre-processing" to "Autocompleted". The Task never enters an "In Progress" or "Started" state, so Users will not see a "Task Started" event for it.