Decisioning Implementation

Decisioning Implementation

When deciding how to integrate Darwinium decisions into your Customer Journey there are a number of options to consider. Is it an Edge, Mobile or API implementation. If it's Edge for example do you wish to leverage Proxy Actions so that you can prevent requests from hitting your origin endpoint. Do you wish to forward signals and scores to the origin so that the origin can make a decision. Do you need to wait for the a response from the origin first?

In this article we will walk through the options and provide some examples. The options proposed within this documentation can work together within a customer journey so to solve a use case you can use a combination of them all together if needed.

Edge Implementation

It is possible to include a combination of all 3 options discussed for an Edge Implementation.

1. At the point DWN assesses the request we can.

• Prevent call to origin by providing a proxy response redirect/error (can prevent SMS messages being sent)
• Pass signals and scores to origin
• Call an External URL to enrich or raise a ticket in an internal system/database

2. At the point DWN assesses the request we can.

• The receiving API can us signals passed in headers which can add additional friction in journey
• Can call Darwiniun REST API

3. At the point DWN assesses the request we can.

• Modify/Proxy response back to device
• Pass signals and scores back to device
• Call an External URL to enrich or raise a ticket in an internal system/database

SMS Pumping Example

Use Case SMS Pumping – prevent flagged users from triggering SMS flows to reduce the cost

For known trusted users on the same device do not trigger SMS flow

1. At the point DWN assesses the request we can we are able to take the identifiers provided from the device and by the user e.g. username, phone number and calculate the signals

• Does the user have any labels to block device/username/phone – if so proxy response to send an error back to the device – reduce the cost of SMS being triggered
• Has the user been seen before on this device recently from current location  – if so this user is trusted so avoid sending SMS by sending a successful response
• All other traffic forward through to OTP API

Enforcing Multi Factor Authentication Example

Use Case to prevent payments for those accounts/devices/usernames that have been blocked

For risky transactions trigger a MFA in the Payment flow

For trusted/safe transaction allow without friction

1. At the point DWN assesses the request we can we are able to take the identifiers provided from the device and by the user e.g. username, phone number and calculate the signals

• Does the user have any labels to block device/usernames – if so proxy response to send an error back to the device prevent payment call being made
• Does the payment look risky e.g. amount out of the norm, beneficiary, location, new device etc – if so inject a header to notify of triggering of MFA
• If the payment does not look risky do not inject header value

2. The Payment API will consume the headers provided by Darwinium and will instigate a MFA auth flow e.g. push notification to known device/phone call to user to verify identity

SMS Pumping API Example

Use Case SMS Pumping – prevent flagged users from triggering SMS flows to reduce the cost

For known trusted users on the same device do not trigger SMS flow

• The device will pass the DWN Profiling Blob (optional) to the OTP API.  The OTP API will then call the DWN API including the Blob, and user identifiers and transaction data
• DWN API will process payload returning in the response signals and scores for the model executed and a decision
• The OTP API will handle the Darwinium response before continuing the execution of it’s code determining the customer experience