Architecture Overview

Darwinium Architecture Overview

Darwinium is a fraud and abuse prevention platform that delivers continuous protection across the digital perimeter.  It is provided as SaaS: Darwinium hosts the decision engine, journey orchestration, and analytics, while integration components run within your own infrastructure - your website, mobile apps, CDN, and backend.

This article outlines the components of the platform and the architecture of each deployment option.

Darwinium Platform

Darwinium Cloud Platform

The SaaS backbone. It hosts the journey repository (a Git-style, version-controlled store of journey configuration with branch, review, and promotion workflows), the orchestration service that deploys configuration to edge nodes, the real-time risk engine that evaluates features, rules, and machine-learning models, the Event API server, and the analytics data plane backing investigations and dashboards. The integration facilitates the encrypted event data to be stored in a region that satisfies the data protection and privacy regulation that applies to you.

Darwinium Portal

The web-based console through which your risk team - fraud analysts, risk engineers, and administrators - interacts with the platform: forensics and investigations, the journey/workflow editor, integration management for edge nodes, incident management, plus dashboards, reporting, and administration of users and roles. Your risk team logs in via your own self-serve SSO (SAML/OAuth/OIDC), with role-based access control governing what each user can see and do.

Darwinium Profiling

Protection begins client-side with Darwinium profiling that runs on end user's device.

On websites this is via Darwinium JavaScript 

1. JS loaded through a Tag on the page
2. JS inserted dynamically by your CDN
   
   

On mobile app this is via the Darwinium SDK  

1. Native Android - install via maven repository
2. Native iOS - install via SPM or Cocoapods
3. React Native
4. Flutter

Darwinium profiling collects device forensics and behavioural biometrics (keystroke, mouse, touch, and sensor dynamics) at the point of interaction. On the web this is Darwinium JS, served first-party from your own domain; in your native apps it is the Darwinium Mobile SDK, which adds mobile-specific signals such as root/jailbreak and app-integrity indicators. 

In both cases the collector produces an opaque base64-encoded protobuf profiling blob that is attached to a request the client was already going to make - as the dwn-profiling header (or can be in the request body for form POSTs). 

For web, there are two ways to get the JavaScript onto the page. Where a Darwinium edge worker is deployed in your CDN, it can insert the profiling script into pages dynamically as they are served - zero application change. Alternatively, you place a Darwinium Tag on the page, which loads the profiling script dynamically on each page load - the standard approach where CDN-level insertion isn't used.

Darwinium Events

A decisioning Event occurs when a request reaches Darwinium's decision engine. 

1. via a Darwinium edge worker in your CDN
2. OR through your backend calling the Darwinium Event API

Both paths return a real-time risk assessment and feed the same journeys, features, models, and investigations tooling in the Darwinium Cloud Platform. An Event appears as row of data in the Darwinium Portal.

Event Integration 1: CDN deployment

In the CDN model, a Darwinium edge worker is deployed into your own CDN account and sits on the routes defined in your journey's steps. 

• Cloudflare: Darwinium Worker with KV stores for edge state - existing workers facilitated via service bindings
• AWS CloudFront: Lambda@Edge - Darwinium-managed routes - existing lambdas facilitated
• Akamai: Linode cluster in your own Akamai account, Akamai Property Manager rule routing the journey's paths to them. 

1. Darwinium gets onto the client: the edge worker inserts Darwinium JS into pages as they are served (alternatively, a JS Tag on the page loads it), and the Darwinium SDK is embedded in your mobile app.

2. Darwinium profiling collection runs client side - device forensics, connection assessment, behavioural biometrics

3. Application request carries the profiling blob in the dwn-profiling header into the edge worker, which extracts and strips it before anything reaches your origin.

4. By default, the worker then forwards the request to your origin directly without waiting; minimal user latency.
This becomes synchronous if the journey in Darwinium platform is configured to wait for Darwinium risk assessment to:
- insert intelligence into headers (eg. risk score) inline, for backend receiving request
- or using Darwinium risk assessment to act on request directly at the Edge worker (eg. terminate, redirect)

4a. sends profiling and event data to Darwinium for risk assessment, async by default
4b.if journey configured to wait for it, Darwinium returns its risk assessment - signals, scores, decision, device attributes - back to the worker

5. You act in your backend on any risk data passed through: allow, step-up, block, or review.

6a. In parallel, the worker asynchronously logs encrypted event data to your S3 bucket
6b. the Darwinium Cloud Platform logs anonymised and decisioning data alongside it; encrypted data is decrypted in your risk team's browser when using Darwinium Portal.

Event Integration 2: API deployment (EventAPI)

In the API deployment, the client's request goes to your backend as normal, with the Darwinium profiling blob included (whether on header or in body). Your backend extracts the blob and includes it as the dwn-profiling header on a POST to a Darwinium Event API step - authenticated with client certificates (mutual TLS) - along with any business context only available at your origin (customer identifiers, payment details). 

Darwinium processes the event through the same decision engine and returns the full risk assessment in the response body: signals, model scores, decision-strategy results, and profiling enrichment such as device identifiers and IP geolocation. 

Optionally, a Darwinium Outpost can sit on the EventAPI path inside your own domain, anonymising data before it leaves your perimeter and logging encrypted event data to your S3 bucket, performing same duty as Edge worker on CDN deployment.

1. The Darwinium JS Tag is on your page; the Darwinium SDK is embedded in your app. 

2. Darwinium profiling collection runs client side - device forensics, connection assessment, behavioural biometrics

3. The client makes a regular request to your backend with the profiling blob attached as the dwn-profiling header. 

4a. Your backend extracts the blob and includes it as a header on the POST to the Event API, over mutual TLS, together with business context (optionally via an Outpost in your domain).
4b. Darwinium returns the risk assessment in the response body. 

5. You act - allow, step-up, review, or block

6a. (optional) Outpost logs async the encrypted event data to your S3 bucket
6b. The Darwinium Cloud Platform logs anonymised and decisioning data alongside it; encrypted data is decrypted in your risk team's browser when using Darwinium Portal.

CDN and API paths therefore can combine naturally: edge steps for protecting endpoints, API steps wherever origin-side context or a backend decision point is needed.

Choosing between Event deployments

Both paths share the event data, journey models, and one investigations surface

Feedback: closing the loop

Darwinium decisions improve when confirmed outcomes are fed back in. Two mechanisms exist.

Labels

Labels mark collections of identifiers with a confirmed disposition or outcome - confirmed fraud on a journey_id, a mule account's email + device, a trusted device + account pair after 2FA. Each label has a name from a fixed list (see Label Reference) and contexts that add detail: a confidence level (confirmed / probably / reasonable / slight, so you can label without 100% certainty) and an auto-assigned source (rule, analyst, api, model).

Labels can be applied:

1. programmatically via the Label API: add/remove, same mutual-TLS certificate authentication as the Event API
2. automatically via Darwinium rules: AddLabel / RemoveLabel rule types, with checkLabel functions reading labels in real time during decisioning.
3. manually by your risk team in the Darwinium Portal. Labels tab, or directly from an event's details in Investigations.

Labels consolidate what are typically otherwise cumbersome separate processes:

• Being available to read in real-time, for rules that automatically influence overall decision
• Binding collections of attributes together, based on criteria
• Available to search over and manage as lists (passlist, blocklist, watchlist)
• Supplying the 'truth data' for machine learning models to train and optimise decisions on

Update API

Where Labels mark identifiers with outcomes, the Update API updates an already-processed event with information that arrives later. 

Like the Event API, it is authenticated with client certificates (mutual TLS); your backend calls it with the `identifier` of the event to update, together with the attributes to apply.

Example use case:

• a final transaction outcome - so the event record, features, and analysis reflect it.
• customer identifier, only assigned after application has been reviewed and approved
• a downstream authentication result 

Data minimisation, residency, and access

Journey configuration determines exactly which request paths and fields are captured; sensitive input can be hashed or excluded at capture, so the stored event record is a deliberate subset of your traffic. All journey configuration lives in a version-controlled repository covered by role-based access control, to ensure every change deployed is reviewable, attributable, and revertible.

If you require full control of personal data within events, you can enable BYO S3 event storage: the edge worker logs encrypted event data to your own S3 bucket, with the Darwinium Cloud Platform logging anonymised and decisioning data alongside it. Encrypted data is decrypted in your risk team's browser when viewed through the Portal - supporting data residency, independent backup, lifecycle/TTL management, GDPR erasure workflows. 

Export to analytics platforms such as Databricks or Snowflake is also supported.