Configuring ODS: Screening Resolution & Materiality
This guide is for Journey Builder administrators and compliance configuration teams. It covers everything needed to enable and configure the ODS: Screening Resolution & Materiality task — the combined v2 task for on demand screening.
Looking for analyst workflow guidance? For day-to-day task usage, match resolution, materiality assessment, and escalation steps, see Using ODS: Screening Resolution & Materiality.
What this guide covers
- Task type activation
- Journey Builder task setup and available toggles
- Escalation configuration (two-task pattern)
- Classification Data requirement categories
- Required Reference Data lists
- Permission assignment
- Key system validations and constraints
Prerequisites
Before configuring the v2 task, confirm the following are in place.
| Prerequisite | Detail |
|---|---|
| Task type activation | The ODS: Screening Resolution & Materiality task type must be activated in your environment before it appears in Journey Builder. Confirm with your Fenergo implementation team that this has been done |
| Journey Builder access | Administrator-level Journey Builder access is required to add and configure the task |
| Journey identified | Identify which journeys will use the v2 task. You do not need to remove existing v1 Screening Results or Materiality Assessment tasks — the v2 task can coexist |
| Screening providers configured | Provider integrations must already be in place. The v2 task uses the same provider setup as existing screening tasks |
| Reference Data access | Classification Data requirement categories must be configured in Reference Data before they appear at runtime. Confirm you can add Requirement Categories |
If the ODS: Screening Resolution & Materiality task type does not appear in Journey Builder, it has not yet been activated for your environment. Contact your Fenergo implementation team before proceeding.
Journey Builder configuration
Adding the task
- Open the relevant journey in Journey Builder
- Add a new task and select
ODS: Screening Resolution & Materialityfrom the task type list - Configure the task name, assignment, and SLA as required
- Navigate to the Details tab to configure toggles
The ODS: Screening Resolution & Materiality task type replaces the combination of the v1 Screening Results and Materiality Assessment tasks. Both the old task types and the new v2 task type can coexist in the same environment.
Details tab — available toggles
All toggles on the Details tab are optional. The task functions without any toggles enabled.
Task Content toggles
| Toggle | Behaviour when enabled |
|---|---|
| Task completion with unresolved items | Analysts can complete the task with unresolved matches and incomplete materiality assessments. When disabled, all matches must be resolved and all required assessments must be complete |
| Sanctions proceed decision | When a Sanctions hit is confirmed as a match, the analyst must record an OK to Proceed or Not OK to Proceed decision and enter a rationale before saving the materiality assessment |
| Hit document enabled | Reveals an optional document upload section in the Match Resolution popup. Analysts can upload a supporting document for a hit but are not blocked from saving if they do not. Values for the Document Type selector come from the Document Type Reference Data lookup list. Documents cannot be uploaded after the batch is closed |
| Entity document required | Analyst must upload a supporting document at the entity level. Uses the same Document Type lookup as Hit document enabled |
Assignment Conditions, Scoping Conditions, and SLA Configuration behave identically to existing screening and materiality tasks. No changes are required for those tabs.
Auto-completion behaviour
The v2 task auto-completes when no screening results are returned for any screened entity or related party. No configuration is required — this applies to all v2 tasks automatically. Auto-completion uses the existing exponential backoff mechanism and waits up to seven days for providers to finish before completing.
Escalation configuration
The v2 escalation process uses a two-task journey pattern. Both tasks use ODS: Screening Resolution & Materiality but serve different roles.
Task 1 — Initial Review (first-line analyst)
Add the task as usual. In the task configuration panel, enable the Escalation toggle. When enabled, an Escalate button appears in the Materiality Assessment page. The analyst can select a team or user to notify and leave a comment.
Task 2 — Final Review (second-line reviewer)
Add a second ODS task to the same journey. Configure scoping conditions so it triggers only when escalation has occurred — for example, scope on the Materiality Outcome value from Task 1 (such as Further Investigation Required). Task 2 displays Task 1 outcomes, highlights the escalation comment, and allows the reviewer to override decisions and complete outstanding assessments.
| Setting | Task 1 — Initial Review | Task 2 — Final Review |
|---|---|---|
| Task type | ODS: Screening Resolution & Materiality | ODS: Screening Resolution & Materiality |
| Escalation toggle | Enabled | Not applicable |
| Scoping conditions | Standard conditions (e.g. triggered on case open or OGS completion) | Scope on Materiality Outcome values that indicate escalation is required |
| Assignment | First-line analyst role | Second-line reviewer role |
The Screening Approve permission is not used for v2 escalation routing. Access to Task 2 is controlled entirely by the task's scoping conditions and journey assignment.
Scoping conditions reference — Screening Materiality data source
A Screening Materiality data source is available in Journey Builder scoping conditions (Stage, Process, and Task configuration). Use it to scope Task 2 and any downstream conditional logic based on materiality outcomes.
| Field | Operator | Values |
|---|---|---|
| Main Entity | Equals | True / False |
| Materiality Outcome | Equals / Not Equals | Material / Immaterial / None |
| PEP Materiality Status | Equals / Not Equals | Material / Immaterial / None |
| Sanctions Materiality Status | Equals / Not Equals | Material / Immaterial / None |
| Adverse Media Materiality Status | Equals / Not Equals | Material / Immaterial / None |
| Enforcements Materiality Status | Equals / Not Equals | Material / Immaterial / None |
| Other Materiality Status | Equals / Not Equals | Material / Immaterial / None |
| PEP Jurisdictions | Contains / Does Not Contain | Jurisdiction value(s) |
| Sanctions Jurisdictions | Contains / Does Not Contain | Jurisdiction value(s) |
| Adverse Media Jurisdictions | Contains / Does Not Contain | Jurisdiction value(s) |
| Enforcements Jurisdictions | Contains / Does Not Contain | Jurisdiction value(s) |
| Other Jurisdictions | Contains / Does Not Contain | Jurisdiction value(s) |
| Sanctions Proceed Decision | Equals / Not Equals | Ok to proceed / Not to proceed |
Typical Task 2 scoping for escalation: Combine Main Entity | Equals | True AND Materiality Outcome | Equals | Material (or the value that represents escalation in your configuration).
Multi-process journeys: The escalated task must be in the same process as the initial task. Only entities from the triggering initial task are in scope. The most recent materiality per entity is used if re-screening occurs within the same process. Cross-process and cross-journey evaluation is not supported.
Escalation notifications
To ensure second-line reviewers are notified when an assessment is escalated to them, enable the Screening and Materiality Escalation notification toggle for the relevant users or roles.
Notification text sent: "A materiality assessment has been escalated to you by {user}. Comment: '{escalation comment snippet}' Click to review the journey."
The notification includes a direct link to the relevant journey.
Classification Data setup
Classification Data fields let analysts capture policy-driven context when they confirm a match. Fields appear in the Match Resolution popup only when the analyst selects Match. They are hidden for No Match and Unresolved decisions.
Requirement categories
The five screening classification categories must be explicitly created in Reference Data as Requirement Categories. The system resolves which fields to display by looking up these names at runtime.
Critical: These names are fixed. The system will not recognise categories with different names or casing. Use the exact names below.
| Requirement Category name (exact) | Applies to hits in this category |
|---|---|
Screening Classification Data PEP | PEP (Politically Exposed Person) hits |
Screening Classification Data Sanctions | Sanctions hits |
Screening Classification Data Adverse Media | Adverse Media hits |
Screening Classification Data Enforcements | Enforcement hits |
Screening Classification Data Other | Other category hits |
You do not need to configure all five. A missing category shows no Classification Data fields for that hit type — it does not cause an error.
Policy field naming convention
Once a Requirement Category exists, add policy fields to define the Classification Data fields that appear in the popup.
Database field name convention: Every Classification Data policy field must include the string ClassificationData in its database field name. Fields that do not follow this convention may conflict with other policy fields at runtime.
Example of a valid name: pepClassificationData
Example of an invalid name: pepType
| Field display name | Database field name (note ClassificationData in each) |
|---|---|
| PEP | pepClassificationData |
| Jurisdiction | jurisdictionClassificationData |
| Enforcements | enforcementsClassificationData |
| Adverse Media | adverseMediaClassificationData |
| Other | otherClassificationData |
Required Reference Data lists
Screening Materiality Jurisdiction list
Create a Reference Data lookup list named exactly Screening Materiality Jurisdiction. This list provides the jurisdiction values analysts select when completing a materiality assessment. Without it, the jurisdiction dropdown in the materiality overlay will be empty.
| Setting | Required value |
|---|---|
| List name | Screening Materiality Jurisdiction |
| List type | Standard Reference Data lookup list |
| Values | Jurisdiction values appropriate for your organisation — country names, regulatory regions, or a combination |
The list name must be exactly Screening Materiality Jurisdiction. A different name results in an empty jurisdiction dropdown at runtime.
Match resolution reason lookups
These are unchanged from Screening v1. No new setup is required if you already have v1 reason lookups configured. If setting up v2 in an environment that has never had Screening v1, create reason lookups following your existing v1 Reference Data process.
Document Type lookup
When either Hit document enabled or Entity document required is enabled, the analyst sees a Document Type selector. This is populated from the existing Document Type Reference Data lookup list — no new list is needed. Add document type values relevant to screening evidence.
If you enable either document required toggle without ensuring values exist in the Document Type lookup, analysts will see an empty dropdown and will be unable to save decisions.
Entity type scoping
Control whether a Classification Data field applies to individuals, companies, or both via the Entity Type setting on each policy field.
| Scenario | How to configure |
|---|---|
| Field applies to individuals only | Set Entity Type to Individual |
| Field applies to companies only | Set Entity Type to Company |
| Field applies to both | Set Entity Type to both Individual and Company, or leave unscoped |
Client vs Related Party scoping is not currently supported. A Classification Data field configured for a screening category applies regardless of whether the screened entity is the main client or a related party.
Supported field types and limits
| Field type | Notes |
|---|---|
Text (text) | Single-line free-text input for short descriptive context |
Text area (textArea) | Multi-line free-text input for longer narrative or detail |
Date (date) | Date picker for recording a specific date value |
Single select dropdown (select) | Analyst selects one value from a predefined Reference Data list |
Multi-select dropdown (multiselect) | Analyst selects one or more values from a predefined Reference Data list |
Maximum four Classification Data fields per screening category. Journey-level data, data groups, and custom properties are not supported.
Classification data reuse
Once Classification Data is saved for a confirmed match, the system automatically reuses it when the same hit alerts again for the same entity in a subsequent screening. No additional configuration is required. Reuse is an extension of the existing screening reuse mechanism.
Technical note: Classification data for reuse is returned by GetMatchById, not GetAllMatches. This is by design to ensure data is retrieved in the correct category context.
World-Check One (WCO) behaviour: WCO maintains cross-journey resolution reuse natively — the standard FenX screening reuse mechanism does not apply to WCO resolution data. For classification data specifically: when WCO returns a true match, classification data from the most recent prior completed WCO screening journey for the same hit is reused automatically. When WCO returns no results, classification data from the prior journey is not reused. The same logic applies in reopen flows.
End-to-end configuration example
This example walks through a complete Classification Data setup for a PEP screening category — from Reference Data creation to analyst runtime experience.
Scenario: Capture two additional data points when a PEP match is confirmed — a PEP Level (single select dropdown) and a free-text note.
Step 1 — Create the Requirement Category
Navigate to Reference Data → Requirement Categories and create a new category with the name:
Screening Classification Data PEP
The name must be exactly Screening Classification Data PEP including capitalisation and spacing.
Step 2 — Create the PEP Level dropdown list
Navigate to Reference Data → Lists and create a new lookup list.
| Setting | Value |
|---|---|
| List name | PEP Level (or your organisation's preferred name — this is flexible) |
| Values | Level 1, Level 2, Level 3, Foreign PEP, Domestic PEP (or equivalent) |
Step 3 — Add policy fields to the Requirement Category
Return to Screening Classification Data PEP and add two fields.
Field 1 — PEP Level dropdown
| Setting | Value |
|---|---|
| Database field name | PEPClassificationDataLevel |
| Display label | PEP Level |
| Field type | Single select dropdown |
| Lookup list | PEP Level (created in Step 2) |
| Entity Type | Individual and Company |
Field 2 — free-text note
| Setting | Value |
|---|---|
| Database field name | PEPClassificationDataNote |
| Display label | Additional context |
| Field type | Text field |
| Entity Type | Individual and Company |
Step 4 — Create the Screening Materiality Jurisdiction list
This step is required once per environment. If the list already exists, skip to Step 5.
Navigate to Reference Data → Lists and create a list with the name:
Screening Materiality Jurisdiction
Add the jurisdiction values your analysts will select.
Step 5 — Configure the Journey Builder task
Add ODS: Screening Resolution & Materiality to the relevant journey and configure toggles as required on the Details tab. Enable the Sanctions Proceed Decision toggle if your policy requires it.
Step 6 — What the analyst sees at runtime
| Analyst action | System behaviour |
|---|---|
| Opens a PEP hit | Match Resolution popup opens |
| Selects Match | Classification Data section appears with PEP Level (dropdown) and Additional context (text) |
| Selects No Match or Unresolved | Classification Data section is hidden |
| All hits resolved with at least one Match | Materiality assessment becomes available. Jurisdiction lookup shows values from the Screening Materiality Jurisdiction list |
Permissions
Screening permissions are unchanged from the existing model. No new permission types are introduced.
| Permission | What it allows |
|---|---|
| Screening Access | Read-only access to screening results, classification data, materiality assessments, RP-level decisions, and historical decisions. Users see the eye icon only |
| Screening Edit | Full edit access while the task is In Progress. Users can resolve matches, enter classification data, and complete assessments |
| Screening Approve | Not used for v2 escalation routing. Escalation is configured via the Escalation toggle in Journey Builder. See Escalation configuration |
Read-only after task completion: Once the task reaches Completed status, all users have read-only access regardless of their assigned permission. No additional configuration is required.
Journey Builder permissions: Standard Journey Builder configuration permissions apply. No additional permissions are needed beyond those already required for Journey Builder administration.
Key validations and system behaviours
Validate the following in a test environment before deploying to production.
| Area | Validation or rule |
|---|---|
| Provider status tracking | Providers are tracked independently. Completed, In Progress, and Error states can coexist. An error in one provider does not block others |
| Search criteria display | Only configured secondary identifiers appear. Empty or unselected criteria are not shown |
| Match comments | Maximum 1,000 characters per the WCO limitation |
| Classification Data fields | Only text, single select, and multi-select are supported. Maximum four fields per category |
| Classification Data visibility | Fields shown only when Match decision = Match. Hidden for No Match and Unresolved |
| Materiality invalidation | If a Match Decision is changed after a materiality assessment is saved, the system invalidates the assessment and requires a new one. Changing only reason, comments, or classification data does not trigger this |
| Materiality conditions | Materiality assessment becomes available only when: (1) all providers have completed, (2) at least one confirmed match exists, and (3) all hits for the entity are resolved |
| Auto-completion | If no screening results are returned for any entity or related party, the task auto-completes. Materiality UI, classification data entry, and escalation flows do not appear |
| Reporting | EntityMaterialityAssessment is included in the BatchEntity model in Athena (Advanced Reporting). No additional configuration required |
| Audit trail | All v2 audit events are surfaced in the audit panel. Classification changes: MatchesUpdated rows show Classification Data fields before and after, plus the ActionedOn timestamp. Materiality changes: "Entity Materiality Assessment Updated" rows show Rationale, per-category MaterialityStatus, Jurisdictions, and OkToProceed before and after. Document events: Distinct labelled rows for Document Added, Removed, Status Updated, Archived, and Unarchived — each expandable with file name, document type, and status details. |
| Document preview | When a document required toggle is enabled, uploaded documents can be previewed from within the task. No additional configuration needed |
| OGS-triggered hit highlighting | When an ODS task is triggered by OGS, hits from the OGS batch are automatically highlighted in the results table. No additional toggle required |
Risk calculation integration
When the ODS task completes, the system writes six OOTB policy fields to the main entity's policy record. These fields can be used to drive risk calculations, conditional task routing, and downstream policy logic.
Policy fields written on task completion
| Field name | Values | Description |
|---|---|---|
FinalMaterialityPEP | Material / Immaterial / No Impact | Worst-case PEP materiality across main entity and all related parties |
FinalMaterialitySanctions | Material / Immaterial / No Impact | Worst-case Sanctions materiality across main entity and all related parties |
FinalMaterialityAdverseMedia | Material / Immaterial / No Impact | Worst-case Adverse Media materiality across main entity and all related parties |
FinalMaterialityEnforcements | Material / Immaterial / No Impact | Worst-case Enforcements materiality across main entity and all related parties |
FinalMaterialityOther | Material / Immaterial / No Impact | Worst-case Other materiality across main entity and all related parties |
OverallMateriality | Material / Immaterial / No Impact | Derived from the per-category values (see below) |
Aggregation logic
For each per-category field, the value is the highest severity across the main entity and all related parties, using the order: Material > Immaterial > No Impact. Per-related-party values are inputs only and are not persisted on the related party object.
OverallMateriality derivation:
- Material if any per-category field is Material
- Immaterial if no category is Material but at least one is Immaterial
- No Impact if all per-category fields are No Impact
Cross-journey behaviour
When a new screening run completes in a subsequent journey for the same entity, the FinalMateriality fields are overwritten — including being reset to No Impact if the new screening yields a different outcome. If a journey runs with no screening, previously stored values persist until the next screening run triggers a recalculation.
Risk Assessment re-evaluation is triggered when materiality is updated mid-journey (for example, after a rescreen).
Out of scope (Day 2)
The following are not included in the current release and are planned for a future phase: per-related-party Final Materiality persistence; per-jurisdiction materiality; graded materiality scale; Screening Classification Data exposure to Risk; cross-journey delta evaluation; threshold-by-relationship-type aggregation.
Known limitations
| Limitation | Detail and status |
|---|---|
| Client vs Related Party scoping not supported | Classification Data fields cannot behave differently for clients versus related parties. A field configured for a screening category applies to all entities of that type regardless of whether they are the main client or a related party. This is not planned for v2 |
| On-demand screening assumed | The v2 task assumes an on-demand screening process is already configured in the environment. No additional configuration domains are required beyond those documented in this guide |
If a limitation blocks a specific use case, contact your Fenergo implementation team or raise it via the standard product feedback process.
Screening Assessment Outcomes tab on Entity Profile
The Screening Assessment Outcomes tab surfaces consolidated screening history directly on the Entity Profile page for entities processed through the v2 task. It is controlled by a toggle in View Configuration.
Enabling the tab
Navigate to View Configuration and locate the Entity Profile section. Enable the Enable Screening Outcomes Tab on Entity Profile toggle.
Toggle tooltip: "If you are using the 'ODS: Screening Resolution & Materiality' task in your journeys, switching this toggle will enable a new Screening Outcomes Tab on the entity profile."
Once enabled, the tab is visible on the Entity Profile page for all entities with v2 materiality assessment history.
This setting applies across all users and entities in the environment. Role-level or user-level visibility control is not available.
Behaviour summary
| Scenario | Behaviour |
|---|---|
| Entity has v2 ODS task history and toggle is enabled | Screening Assessment Outcomes tab appears on the Entity Profile page |
| Entity has v1 task history only | Tab is not displayed, even when the toggle is enabled |
| Toggle is disabled | Tab is hidden for all entities |
Latest Materiality Assessment Results on the Data tab
The Data tab of the Entity Profile includes a Latest Materiality Assessment Results section. This section reflects v1 task data only and is separate from the Screening Assessment Outcomes tab.
For v2 screening history, analysts should use the Screening Assessment Outcomes tab. The Latest Materiality Assessment Results section on the Data tab shows v1 task data only.
Glossary
| Term | Definition |
|---|---|
| ODS | On-Demand Screening. The ODS: Screening Resolution & Materiality task type is the v2 combined task |
| OGS | Ongoing Screening. A periodic screening workflow using the OGS: Screening Resolution & Client Selection task type |
| RP | Related Party — an individual or entity associated with the main legal entity |
| Classification Data | Policy-driven context captured for confirmed matches, configured per screening category in Reference Data |
| Requirement Category | A Reference Data configuration object defining the Classification Data fields for a screening category |
| Materiality assessment | The analyst decision on whether confirmed screening results are material for the entity or related party |
| Overlap | A prior batch containing hits also identified as confirmed matches in the current batch |