Skip to main content

Glossary and Conventions

General Terms​

Like any Software Vendor, Fenergo have created terms and Conventions which describe our platforms features and how they relate to the business outcomes they deliver on. Familiarity with such terms

The bell​

The Notifications Icon that expands the Notifications inbox popover in the UI.

Chip​

Chips are the colorful icons used to indicate in-scope policies, in multi-select dropdowns, in statuses, and more.

Entity​

An Entity is any individual or company in Fenergo SaaS. This can be a client, or the related party of a client.

Entity profile page​

This page summaries the latest verified data of an entity. The page gives a summary of all data, journeys, and relationships on the entity. Note that the same page is used for Clients and Related Parties.

Out of the box (OOTB)​

An out-of-the-box feature or functionality, particularly in software, is a native feature or built-in functionality of a product that comes directly from the vendor and works immediately when the product is placed in service.

Toast​

UI “quick messaging” to inform a user of an action that the system has performed, will perform or whether a warning/alert has been triggered.

Version​

Configuration elements are versioned before changes are made, in order to protect the integrity of legacy data and to make updates to configuration safely. When a Journey is initiated, it calls the relevant updated version of the policy, risk, screening scope, etc.

Journey​

Journey's encapsulate the various activities that need to be completed to process a CLM event. A simple example is the Client Onboard journey, which contains all the tasks, processes, and stages that must be completed to successfully onboard a client. Best practice journeys are provided with each tenant and can be configured to a client’s specific requirements.

Stage​

A Stage is a collection of Processes (and their respective tasks) in a Journey. A Stage will act as a key reference / checkpoint in a Journey that must be completed before the Journey can be closed.

Process​

A process groups together a set of similar tasks. One or more processes may be contained within a stage. Processes are a way of organising similar tasks.

Task​

Tasks are where the action happens; when a user updates a client in Fenergo SaaS, they will do that in a task. For example, there are tasks for data capture, a task for risk calculation, a task for screening, for external data ingest, for document upload, etc. A simple differentiation between tasks and stages/processes is that tasks are where actions are completed, and processes and stages are there to neatly organise tasks.

Journey Hub​

This is the overview of the entire customer journey, from which point the user can access tasks and complete their actions.

Client Status​

Client Status indicates whether the entity is a client or not. The simple rule for Client Status is that an entity that has successfully gone through a Client Onboarding journey, and had their data verified at the end, is flagged as a client.

Lifecycle Status​

This is a snapshot view of where the client is in their CLM journey. It can be thought of as a summary of the journey or journeys that the customer is in. So they may be ‘Onboarding in Progress’, ‘Review in Progress’, or ‘Compliant’ if they are onboarded with no active journeys.

Journey Builder​

This is the visual configuration suite that allows users to update existing journeys and create brand new ones. For example, we may want to add in a new review task, or consolidate 3 data capture tasks into 1.

Verified LE Record / Draft LE Record​

Whenever a new journey is created (e.g., a Maintenance or Periodic Review journey), a new draft record of the verified entity data record is created. The existing verified record is not changed. Any updates to the entity data happen to that draft record. This means that if we cancel the journey, then we can simply discard the draft and revert to the existing verified record. Alternatively, once we hit the Verify Data task in the journey then that draft record becomes the new verified record, in effect becoming a new version of that verified record. This lets us review previous versions of the entity profile at points in time.

Policy​

A Policy in the Fenergo SaaS platform is where clients can configure their data models (what you want to capture). Define all the Data, Document and Ownership/Control Requirements by jurisdiction with fully configurable scoping conditions and rules.

Trigger Conditions​

These are used when a requirement should appear in certain circumstances only, rather than statically appearing. For example, we may only ask for the ‘Regulated By’ field when the ‘Regulated Entity’ field is set to Yes.

References​

References let us capture the reason why we require a datapoint, document, or relationship. This is typically used to refer to the legislative text that enforces the requirement, but is kept flexible so that it can be used to capture references to a bank’s internal policy documentation too.

Data Group​

Data Groups are flexible sets of data. As standard they are used for Addresses, Tax IDs, Previous Names, and Products, but can be extended to any requirement. The can be captured in a 1:many relationship against the entity, for example in the situation where a client has multiple different types of address.

Lookup​

Lookups are the reference data of the system. They are used to in dropdowns like Country, Company Type, and Industry Codes.

Linked Lookup​

This is simple too dependent lookups, where one list should filter the other. For example, choosing a Product Category of ‘Credit’ should limit the options in the Product Type list.

Lookup Metadata​

This refers to the characteristics of a lookup value. For example, metadata for Canada on the Country lookup might be the currency, the risk level, the sanctioned flag, the ISO code, and the time-zone. These are typically used in rules.

Data Requirements​

Customer profile information that is required to be captured about the client. These attributes are presented to the user in a journey.

Document Requirements​

Mandatory documents that must be captured for a client, including acceptable document types that can be used to satisfy each requirement e.g. a passport is an acceptable document for a Photo ID document requirement.

Ownership and Control Requirements​

The minimum set of related parties that must be captured e.g. UBOs, Directors, Authorised Signers. These rules also include the data and document requirements against those related parties. These are commonly referred to as ID&V requirements.

Screening​

Screening is completed against the client and their in-scope related parties to determine if there are any PEPs, Sanctions, or Adverse Media against them, with the aim of determining the AML risk category appropriately. Fenergo SaaS uses external services like RDC and LexisNexis for this.

Match Resolution​

Once a hit has been returned from a service, it must be confirmed as a valid match. It is common to have many hits returned for a common name that refers to a different person. For example, one might get 1,000s of returned for a name like John Smith, only a handful of which relate to the ‘right’ John Smith.

Materiality​

Once the match is confirmed, the materiality of the hit must be assessed. This is separate to matching, in that we are no longer determining whether the hit relates to the right person or not, but instead if the event that the screening hit describes is serious enough to warrant escalating the risk level. Sometimes minor events do not matter, for example if a client used to be a local councillor in a small town, then we would not consider them a PEP.

Risk​

When using a Risk Based strategy to govern what to collect and when, flexible and fully configurable risk models can help automate the decision making process and meet regulatory requirements.

Risk Model​

The Risk Model contains the risk factors (Country, Industry Code, Product) the values, and the weights of each are defined.

Risk Configuration Model​

The Risk Configuration Model details the scores that each risk factor contributes to the overall risk score, and the calculation method of each factor.

Risk Threshold Model​

The Threshold Model stores the various risk score limits that must be reached to trigger Low, Medium, or High risk (or whichever new levels a client configures in).

Risk Scoping Rules​

Risk Scoping Rules determine when a particular Risk Configuration Set should be triggered, based on the client profile.

Risk Score​

The Risk Score is the accumulated total of the risk factors, expressed as a single number.

Risk Category​

The Risk Threshold will trigger a specific risk category (Low, Medium, High, etc.)

Calculator​

The Risk Calculator allows users to sample different client profiles and test out the risk model that results. The various risk factors scores and overall score and category are displayed.

User Access Management​

Controlling what a user can do and what groups have access to what data is vital to protect data.

A permission is the basic unit of user access. There are specific permissions for different areas of the system and actions within it. For example, a permission to create a journey, configure a risk model, or approve screening results.

Team​

The Team groups together a set of permissions to let a user access areas of the system and complete defined actions.

User​

Each user is assigned to one or more teams that will determine what they can do within the system.

Access Layer​

As Teams control access to areas of the system, Access Layers control access to data in the system. This is typically broken down on geographical lines but can also be based on business line or similar. There is a graduated level of access depending on the country-specific data privacy rules, from open access to limited access to complete obfuscation of the existence of the entity.