Retail Origination Application integration with FCM

Retail Origination interaction with FCM supports the following capabilities:

• Customer Sanctions and PEP Matching
• KYC Customer Risk Assessment

Any customer application that does not trigger a hit, will proceed as straight through processing (STP).

For more details on these FCM features, see https://saasdocs.temenos.com/saas/docs/services/RES/FCM_UNI/RES23/Universal/Product_Config/FCM.htm

The Retail - FCM Scan Service

If your RES configuration includes FCM, and the applicant is a new customer, this service is invoked.

After the customer submits the Address and Identity Details screen, the Narrative calls the Retail – FCM Scan service, and passes the applicant's first name, last name, and date of birth. 

The service makes a call to FCM by way of an API that requires an OAuth access token.  Once the application has the access token, the endpoint (configured in the Service Connection for the Retail - FCM Scan service) will be invoked and added to the context path /vrisk/web-services/api/v1/computations/screen/onboard/scan/json. 

The API documentation is available from https://developer.temenos.com/service/sanction-screening#tag/Transaction-Message-Scan/operation/postjson. 

Once invoked, the Retail – FCM Scan service constructs a JSON request like the following example:

{
		    "onboarding_scan_request": {
                "entity": {
                    "entity_type": "individual",
                    "individual_info": {
                        "birth_date": "1970-10-12"
                    },
                    "names": {
                        "original_name": {
                            "first_name": "John",
                            "last_name": "Smith"
                        }
                    }
                },
                "mandator": "GB0010001",
                "requester": "CUSTOMER",
                "version": "1.0"
            }
        }

The values birth_date, first_name and last_name come from the Narrative as noted earlier, except for mandator which is the company ID maintained in the configuration service parameter origination-common-companyId. 

The FCM scan API returns a JSON payload like the following:

{
          "scan_response": {
            "@version": "1.2",
            "details": [
              {
                "hit_count": 3,
                "hits": [
                  {
                    "record_id": "0a09d9c28cc91777818cc987a377010f",
                    "source_ids": "OFAC"
                  },
                  {
                    "record_id": "0a09d9d48cdf1673818cf7e6c4470002",
                    "source_ids": "PRIVATE"
                  },
                  {
                    "record_id": "0a09d9d48cdf1673818cf87016b50012",
                    "source_ids": "PRIVATE"
                  }
                ],
                "risk": "COFI"
              },
              {
                "hits": [],
                "risk": "HOBM"
              },
              {
                "hits": [],
                "risk": "HVP"
              }
            ],
            "gateway": "ONBOARDING",
            "giexp_timestamp": "2024-01-12 12.06.55",
            "kb_timestamp": "2020-02- 4 15:00:49",
            "message_id": "d4122e4c-4b82-45ad-adbf-8ff7ef9affe8",
            "non_blocking_flag": "BLOCKING_HITS_ONLY",
            "server_port": 0,
            "status": "HIT"
          }
        }

In this example:

• HIT indicates that the applicant was found on at least one sanction list. 
• message_id is the reference to the created record, which is needed later. 
• source_ids (OFAC, PRIVATE, PRIVATE) indicate the lists on which this applicant was found.

The Retail – FCM Scan service parses out these values and stores them as TJM Transaction Details > Properties. 

The service writes the message_id to a property called FCM Scan Message ID and stores the source_id values as a comma-separated list in FCM Scan Hit Source IDs, such as:

Decision Rules

In the Narrative, observe the following:

Note that the Decide service is invoked right after calling the Retail – FCM Scan service and before deciding which page to show next.  That's because the response from Retail – FCM Scan is needed to decide whether to allow this application to continue or decline at this point. 

The relevent decision rules are:

{
              "id": "FCM Scan Decline",
              "destination": "declined",
              "condition": { "in": ["OFAC", { "var": ["txn.propertyMap.FCM Scan Hit Source IDs"] }, "str"] }
            },
            {
              "id": "FCM Scan Review",
              "destination": "fcmScanReview",
              "condition": { "or": [
                { "in": ["PRIVATE", { "var": ["txn.propertyMap.FCM Scan Hit Source IDs"] }, "str"] },
                { "in": ["EU", { "var": ["txn.propertyMap.FCM Scan Hit Source IDs"] }, "str"] }
              ]}
            }
         

There are two rules in the decision-rules.json file. 

1. The first rule, FCM Scan Decline, fires if the string OFAC is in the list of FCM Scan Hit Source IDs.  That rule is associated with the declined destination.
2. The second rule, FCM Scan Review, is associated with the fcmScanReview destination, and is active when either PRIVATE or EU are found in the FCM Scan Hit Source IDs property.

Either of these rules can be updated in this file to map different source IDs to different destinations.

1. If the FCM Scan Decline rule triggers, the applicant sees the decline screen and the process will end. 
2. Otherwise, if the FCM Scan Review rule triggers, the applicant will continue with the application, but when submitting, will see the Application in Review message. The application will then go to the FCM Scan Review queue. 

The result will be available in the collaboration job Actions in Temenos Journey Manager:

Note that the job is currently waiting and has been assigned to FCM Scan Review to be actioned by an individual member of the FCM team. 

Temenos Journey Manager (TJM) uses a scheduled job called Retail – FCM Status Check to periodically go through all transactions in the ‘waiting for FCM’ state, and checks by way of another API call to see if the record has been actioned in FCM.

Evaluating the Hit in FCM

To see the record in FCM, take note of the FCM Scan Message ID in TJM Transaction Details > Properties, log in to the FCM module, and view in the Transaction Alert Manager.

False Alert

In case of a False Alert, the next time the scheduled task Retail – FCM Status Check runs it should progress and approve the application. 

The TJM collaboration job would look like:

True Alert

In case of a True Alert, here's how the collaboration job looks when an application goes to the FCM queue and is evaluated as a true alert.

 

Retail – FCM Status Check Service

The Retail – FCM Status Check service is the scheduled task mentioned earlier that periodically checks to see if the pending records in FCM have been evaluated. 

The service invokes an API using a GET request ending with /vrisk/web-services/api/v1/alert_status/message/[messageId] where messageId is the ID stored in the transaction properties from the initial scan. 

The API is described here: https://developer.temenos.com/service/sanction-screening#tag/Transaction-Message-Scan.  This is just a GET request, so there is no body.  The response is XML and looks like:

The Retail – FCM Status Check service looks for the value in the status tag. 

• A value of PENDING means that the record has not been evaluated yet. 
• A value of DECLINED means that the record was confirmed to be a hit.
• A value of APPROVED means that it was a false alert.

Since customer applications can have multiple applicants, and it is possible that more than one of them is flagged by the FCM scan, the Retail – FCM Status Check service must invoke the API multiple times. 

• If any of the flagged applicants is declined, the entire application is declined. 
• If every flagged applicant is approved, the application is approved.