Functionality Overview

Overview

The Darwinium platform combines:

profiling which collects information about the user as they interact with the site or app.

• Device: identifier token, crypto hash cookie for copying protection, signature for persistence and recognition leniency
• Behavioural biometrics: signatures simplify and cluster behaviour comparisons, touch, mouse, keystroke, sensors for artificial conditions
• Connection: layered technologies for consistency, lookups for context of type, provider, location, proxy/VPNs

real time decision engine, handling comparisons and returning risk assessment

• Features: Remember history, varied timeframes, statistics for modelling
• Rulesets & Signals: human readable signals for justification, control over outcomes
• Models: Scores, ML models, linear scorecards
• Labels: Marking outcomes, keeping lists, binding attributes, model feedback data
• Self-serve Portal: Investigation, customisation and traceability

conditional orchestration orchestrate page content and the request and response to custom URLs. Profiling, data and remediation workflows become easier to design and deliver.

• Page content: deliver profiling tags, or risk based messaging and step-ups directly inline
• Data: pull in enrichment data to make better decision and/or push Darwinium outcomes to external data sources
• Actions: deliver conditional alerts, notifications, queues or tickets to external systems

Device

"What is the device being used, is there something unusual, is it the same as before?"

Device ID

Several token based elements (including cookies, local storage elements and SecureID) are used to derive the Darwinium DeviceID. It is often the best identifier to use for general use cases, rules and models that pivot on device.

Device SecureID

A SecureID is derived by performing a crypto private/public key hash exchange. That is useful for absolute certainty of a user returning on the same browser, as the process is resistant to cookie copying.

Device Signature & Similarity

Signatures are Darwinium's approach to probabilistic identification.
Token based identifiers are increasingly likely to be delete or spoofed.
The device signature uses instead a marginal probability assessment against the underlying device and connection forensics data.
That allows it to persist even when tokens do not.

Signatures also are equipped with a similarity function, giving flexibility when comparing one to another.
An authentication use case may need 100% similarity, or maybe 90% similarity is good enough to give user a better experience

Device Forensics Data

Alongside the device identifiers, the raw underlying data profiled from the device is also supplied, offering the ability to investigate and create logic against more nuances or anomalies discovered.

Behavioural Biometrics

"How is the user interacting, is that unusual for them?"

Behaviour Signatures

Darwinium behaviour signatures condense an aspect of the user's behaviour as an embedding.
Like all signatures, they are identifiers in their own right, but also equipped with similarity functions to compare them.
The benefit? Simple comparison and linking of the behaviour across different sessions, and flexibility to scale the similarity confidence up or down.
Behaviour signatures include:

• Keyboard signature
• Mouse signature
• Touch signature
• Sensor siganture

Behaviour Linking

Signatures of behaviour are displayed and investigated through the interactive Darwinium Behavioural Identity Graph. Links between behaviours and user journeys become easier to identify and assign outcomes to.

Key Presses

Keyboard (physical or virtual) cadence and interaction is profiled, with context of the field that was interacted with. This is important for changing the risk of interaction style. It is more risky for example to see a paste in something like a name field vs. an id number field.

• Timing (time, hesitancy, dwell, flight)
• Shortcut Usage (autofill, paste, copy, cut)
• Navigations (tabs, arrows, backspaces, deletes)
• Style (caps, left/right shift, numpad)

Mouse

When mouse is used, the profile of the movements and clicks are profiled

• Click number (left, right, middle, scroll click)
• Num movements
• Movement profile (curvature, inflexion, distance)
• Movement timing (dwell time, move/scroll interval, speed)
• Mouse off screen

Touch

For phones and tablets, interactions of touch dynamics on the screen take the place of mouse.

• Tap profiles (size, pressure, radius)
• Num swipes
• Swipe profile (left/right handedness, curvature, inflexion, distance)
• Swipe timing (dwell time, move/scroll interval, speed)

Sensors

For mobile devices, sensor information is retrieved. That can be useful for separating natural vs. artificial conditions.

Sensor hardware queried when available:

• Accelerometer
• Gyroscope
• Magnetometer
• Proximity sensor
• Light sensor

To retrieve data aggregations of the following:

• Orientation
• Linear acceleration
• Rotation rate
• Magnetic field strength
• Gravity strength
• Light illuminance
• Proximity

Connection & Location

"How is user connected to internet, is it normal or tries to mask?"

Darwinium layers technologies to probe the aspects of the connection for consistency or anomalies.
Location is also profiled and inferred through several technologies.

Aspects of the request and connection details

• User agent & headers
• Multiple ways of inferring IP for consistency (PRIMARY, CDN inferred, HTTPS, WebRTC, Forwarding, DNS)
• IP context lookups for type, location, details
• Proxy/VPN detection through packet inspection
• HTML/GPS geolocation for more precise location

Features

Darwinium contains an integrated real-time feature store.
That supports decisions to made in context of previous behaviour of the attributes.

Attribute behaviour is surfaced, including:

• velocities
• count distincts
• time since first/last
• distance between/from/to

Statistics are produced for models, including:

• quantiles
• averages
• ranges
• deviations

The features are not fixed and can be customised and extended self-serve.

Rulesets & Signals

Darwinium contains an integrated and self-serve rules engine.
Those rules can use any data in the schema to produce risk signals or form a linear weighted scorecard.

Rulesets:

• trigger human readable signals
• can add together to form linear score

The rules can be customised and extended self-serve to align to the business

Model Scores

Every step in a journey has model scores for different risks.
Executing models that produce scores are best for optimising decisions and setting softer boundaries for invoking action.

Scores are:

• generated from linear scorecards or ML models (PMML format)
• from multiple models looking at different risks in parallel, latency minimised
• used to influence overall decision recommendation

Conditional Orchestration

Darwinium was built with open principles and to easily facilitate other services where beneficial. On any journey step you can:
a. Insert templated prepared scripts into pages (Edge deployments only)
b. Call an external custom URL (API), with dynamic mapping of request and response data.

The orchestration can occur always, or conditionally based on a logical criteria.

Prebuilt template integrations in the Darwinium marketplace make orchestration of common integrations even easier.

Orchestrate page content

Can choose what, where and how to insert additional content onto page (Edge deployment only)
Examples:

• Insert Darwinium JS profiling into page head
• Insert Bot captcha onto page
• Insert conditional, tailorised scam warning text

Orchestrate data

Pull data from external sources and map the response data back into Darwinium schema to enrich decision.
Push inferred data from Darwinium into another system.
Examples:

• Email risk intelligence lookup
• Phone number Sim Swap lookup
• Push Darwinium event data to an internal data store

Orchestrate alerts / cases

Upon risky condition being true, trigger alerts, tickets or queues in external systems.
Examples:

• Populate case management queue, with event details and risk reason
• Trigger email alert/slack notification, with details of event

Labels

Labels can be added to a combination of attributes to be read when seen again.
They make possible an easy method to get outcomes into the system to enforce decisions on again.

They perform combined roles of:

• automatic real time treatment
• list management
• ML model feedback data

Labels can be applied:

• Manually in the Darwinium Portal
• Automatically via ruleset logic
• In bulk via API calls