Useful Articles

• Functionality Overview: High level overview of Darwinium functionality

Integration

• Edge Deployment: Deploying CDN (‘Edge’) profiling

• Tags Deployment: Deploying JS Tags profiling

• SDK Deployment: Deploying mobile SDK profiling

Reference

• Attribute Reference: Darwinium data schema

• Event API Reference: Calling the Darwinium event API

• Labels: Starting point to understand labels

• Label API Reference: Calling the Darwinium label API

🏗️ Integrating Darwinium

The Darwinium team think integrating a fraud & security vendor shouldn’t be so arduous. We’ve taken great efforts to offer approaches that minimise development overhead and cut the usual grief between adaptable fraud prevention vs. development cycles.

That means easy visibility of what a customer is doing with you, whatever channel, brand or journey. All deployments feed into the same consistent Darwinium engine and database; great for a consolidated view of what’s going on within the applications you oversee.

🌐 Websites & Endpoints

Content Delivery Network (‘Edge’)

If your site is delivered by one of the supported CDNs (content delivery network, check with your IT/Devops!), we can integrate directly on requests via edge compute services. Integration just involves providing Darwinium a couple of tokens from the CDN.

The benefit? Covering any new part of the site is as simple as specifying the URL pattern within Darwinium.

• Cloudflare Documentation: Deploys as Workers
  Create/provide:

  • Cloudflare Account ID

  • Cloudflare Zone ID

  • API Token

  • 3x KV Namespace IDs

• AWS CloudFront Documentation: Deploys as Lambda Functions

  Create/provide:

  • CloudFront Distribution ID

  • Deployment Role ARN

  • Lambda Role ARN

• Akamai Documentation: Deploys via Linode

  Create/provide:

  • Linode Personal Access Token

  • Edge & Origin Domain

  • Cluster Load Balancer Hostname

JS Tags / API

For other (or no) CDNs, or when a more familiar deployment style is preferred, we have the Tags/API approach. JS Tags are added on a page to profile, and a follow up API call made to Darwinium to process and decision.

1. Tags Profiling Documentation: Tags on page, collect profiling

2. API documentation: API call for risk assessment

We’ve had the benefit of developing the approach using the latest tech. That means:

• Always get data back: No dropped or missing sessions

• Traceability and control: Over start/stop and error handling

• First party: Doesn’t run as a third party script

You are free to mix and match the way of profiling and creating events. The Darwinium engine and database will consume and display it all the same.

📱 Mobile Apps

SDK / API

For full profiling, Darwinium deploys as native, lightweight SDK (<400kb) for Android and iOS. Profiling is invoked and collected via functions where needed, and decisions processed via an API call.

1. SDK Profiling Documentation: SDK in app, collect profiling:

2. SDK Reference Documentation: Interface reference for Darwinium SDK

3. API documentation: API call for risk assessment

Content Delivery Network

If your mobile app has endpoints served through the CDN, they can be triggered exactly the same as if it were from a site.

There isn’t native profiling data from the SDK, but pulling in knowledge of what a user has triggered through the app in and of itself can be critical. And all that without needing to touching the mobile application code at all.

Summary

The above methods can be used in combination for Darwinium to profile and risk assess journeys across channels.

Profiling

• JavaScript

  • CDN (Edge) inserted dynamically

  • JS Tags inserted manually

• SDK for mobile applications

  • Android

  • iOS

Event Capture

• CDN (Edge) workers triggered on request routes

• API call to Darwinium

🧠 Why Darwinium anyway?

We’ve noticed a trend: The tools used in digital security like WAFs are blunt tools with limited functionality. And traditional fraud vendors are point in time and lack awareness.

Darwinium has been made with core principles that you will see throughout:

• Adapt faster than release cycles: The frustration is palpable. You’re seeing where how you are being attacked. But integrating a new (or existing) vendor means at best a multi-month project. Darwinium was designed to close that loop.

• Persistent recognition, with similarity signatures: Token based persistence is getting harder to do reliably. Darwinium Similarity Signatures persist where others don’t, and give sliding scale of similarity for the recognition. Across the device, behaviour, content and more.

• Justification Always: We hate opaque boxes that spit out a score without justification. Imagine explaining to a customer they’ve been rejected by a machine and you’re not sure why… Eurgh. Yes we provide the high level decisions, but always offer up the data that sits behind that too.

• Privacy: There shouldn’t need to be a tradeoff of privacy for protection. Thats why we have encryption, anonymisation and data residency options that go above and beyond that required of compliance.
  

🔨 What can Darwinium help with?

Getting grief from one of these? Darwinium is a great platform for solving it:

• Abuse prevention: Whether promo abuse, free trial abuse or repeated applications to try to create mule accounts. Darwinium is great at picking that up, linking and consolidating.

  • Behaviour similarity signatures: Easily cluster abuse by their behaviour

  • Count distinct features: Checking for repeated behaviour and linkages

  • Labels: Allow tagging of known abuse to automate away having to see the same actors come along again and again

• Identifying Subtler Automation: Darwinium goes beyond the usual blunt checks (think User Agent and IP) to recognise the more suble signs of automation

  • Behavioural biometrics: Look for more subtle automation signs across touch, sensor, keyboard and mouse inputs

  • Velocity Features: Monitor for spikes in velocities across identifiers

• Trusting more: Darwinium operates in real-time but looks back over all prior interactions to remember what’s ‘normal’ on a per user basis. That gives opportunity for less friction.

  • Device signatures: Device identifier approach which sticks around to re-recognise more users.

• Detecting Scams & Coercion: Traditional fingerprinting gives false trust in cases of scams and coercion

  • Behavioural signatures: Detect big changes on a per user basis, even when on same device, location, network

  • Remote access: Detect with API and natively through behaviour

  • Live call detection: Through SDK