Connected KYC Architecture Overview

Introduction

Use this page as a way to get familiar with the Connected KYC before getting started on customizing or configuring the solution. This page outlines and explains the patterns developed by the Appian Solutions developers to make it easy to navigate and understand the solution when you are making changes. You can find additional examples that show how to customize and modify your solution documented in the Modifying section.

Connected KYC Sites

Connected KYC has three main sites, each targeted at a different user group.

1. Connected KYC: The primary site for all users of the solution. This is where user groups will view their tasks, reports, and records.
2. Connected FS Settings: This site is for business power users of the solution. The groups using this site are responsible for setting up the main Investigation processes and data.
3. System Admin Center: This site is for IT users that typically would have designer or administrator access for the Appian install. This site hosts integration status and toggles for easily turning the integrations on or off.

Primary records and relationships

Connected KYC uses Appian records and record relationships to power the Investigation processes. The two main records included in the Connected KYC solution are: Customer and Investigation records.

Customer records are the highest level of records in the solution and can have many Investigation events. Any piece of runtime data is going to be related to either of these two records.

Explanation of prefixes

Specific prefixes are used for consistency and to give a high level understanding of the object or database table. Prefixes are used to indicate where the object is used and what the object is used for.

AS is the prefix for all objects and database tables that are created and included in the Connected KYC solution. This will help differentiate objects that were shipped as part of the solution. It is recommended that for new created custom objects that implementation teams use a distinct prefix.

The database table names follow the pattern: AS_[Solution]_[Module]_[Table Type]_[Table Name].

The Appian objects in the application follow the pattern: AS_[Solution Name]_[Module]_[ObjectType]_[ObjectDescription].

Solution Prefixes

The Solution prefix options in the application are:

• KYC: indicates that the database table or object is used for the Connected KYC solution only.
• FS (Financial Services): indicates that the database table or objects is a global Financial Services table. Shared FS tables and objects are especially important when there are multiple FS solutions on the environment or planned to be on the environment as all of the FS solutions will share the table.
• CO (Common Objects): indicates that this is an object that is a commonly reused rule throughout the application. These objects are used for consistency throughout the application and across any Connected FS solutions that are in the environment.

Module Prefixes

Module prefixes indicate that certain tables or objects all relate to the same functionality. For example, if you're looking for all tables that affect the KYC questionnaire functionality, QNM will indicate that those tables are related.

The main module prefixes in the application are:

Table Type Prefixes

Table type prefixes are specific to the database tables and indicate what the table is used for.

If a table does not have a table type prefix, it is used as a transactional table. Reference (R) tables hold data that is relatively static and generally used for populating other fields or tables, while template (T) tables hold data that will generate a Investigation.

For example, reference questions from the AS_KYC_QNM_R_QUESTION table populate the dropdown of available questions on the template questionnaire. When the questions are configured on the template questionnaire they are template questions in the AS_KYC_QNM_T_QUESTION table. When the questions are generated at runtime from the template questions, they are then stored in the AS_KYC_QNM_QUESTION table.

The table type prefixes are:

Object Type Prefixes

Object prefixes indicate what type of Appian object is being used in order to help the user understand what is in the object before opening it.

The object type prefixes are:

Common objects

Common objects are objects that are used across the application to help with logic or formatting used consistently. These objects are prefixed with CO. Don't change these objects as they are used multiple places and can cause issues.

Deprecated objects

Some objects may no longer be used within the application, but are included due to potential application upgrade conflicts. These objects will all be prefixed with zzz_DEPRECATED.

Internationalization

The Connected KYC solution can be translated into multiple languages. Note that certain UI text for Connected KYC's interfaces are contained in bundle files. For example, labels, validation messages, tooltips, and instructional text all exists in bundle files. To update this UI text, you update the bundle file that is associated with it.

Note that some dropdown list values are contained in reference data tables. To modify this type of UI text, see Modifying Dropdown Lists. Keep in mind that user-entered text always displays in whatever language the user entered.

Using bundle files

In order to display UI text, the Connected KYC application loads the correct language bundle (or document file) based on the default language that the user has selected.

It is important that each default language available for users to select has a corresponding set of bundle files. For example, if users can select English (United States) or Español from settings, there must be corresponding bundle files for each of these languages.

For interfaces that are in the AS KYC Full Application application, you need to load the entire bundle onto the form to load the UI text onto the interface. You can do this by using a local variable with the rule!AS_KYC_UT_loadI18nBundles expression rule.

The only parameter you need to pass in is called triggerRefresh. Under most circumstances, triggerRefresh can be passed as null.

The triggerRefresh parameter is only needed in cases where internationalization data needs to be reloaded after the user completes an action. For example, after a user adds new dropdown values from the front end the triggerRefresh should be a variable that is updated on completion of that action.

EXAMPLE

1
2
3
4
5
a!localVariables(
  local!i18nData: rule!AS_KYC_UT_loadI18nBundles( 
    triggerRefresh: null
  )
)

The rule!AS_KYC_UT_loadI18nBundles expression rule will automatically take into account the user's language and load the correct UI text. It's recommended that you call this rule in the main form and pass the UI text data to the sub-interfaces as a rule input. Name the rule input i18nData and make the Type anyType.

To display UI text on an interface, for the parameter that specifies the text to display, such as the label parameter, use the rule!AS_CO_I18N_UT_displayLabel expression rule. In the following example, the UI will display Screening Results, which is the value of the lbl_ScreeningResults label key in the bundle file.

The value of the bundleKey parameter is created using:

• The name of the bundle file, without the language suffix (en_us). For example: AS.KYC.AllBundles.
• The label key for the value that you want to display. For example: lbl_NoCountriesAvailable.

The bundleKey parameter in this example would look like: AS.KYC.AllBundles.lbl_NoCountriesAvailable.

1
2
3
4
5
6
7
8
...
local!i18nData:rule!AS_FS_UT_loadI18nBundles(triggerRefresh: null),
  a!formLayout(
    label: rule!AS_CO_I18N_UT_displayLabel(
      i18nData: local!i18nData,
      bundleKey: "AS.KYC.AllBundles.lbl_NoCountriesAvailable" 
    )
  )

Updating bundle file text

To update the text or languages in the bundles files, use the Solutions Customization Suite.

It is also possible to download the bundle file documents directly and update them manually. Be sure to update a bundle file for each language.

Default bundle files

The bundle files that are shipped with Connected KYC are as follows:

• AS.KYC.AllBundles
• AS.KYC.QNM.AllBundles
• AS.KYC.RC.AllBundles
• AS.KYC.TMG.AllBundles

The prefix explanations above also apply to these bundle files. Any bundle file with an FS prefix is a shared file and all references to that label across solutions will be updated.

Feedback