Functionality Overview

Product Capabilities

What: Darwinium is an Intent Intelligence and Risk Platform built around a single question, asked continuously: who - whether human or agent - deserves what style of friction?

Where: It protects websites, mobile apps and backend services from fraud and abuse, while letting genuine customers - and their agents - interact with minimal interruption.

How: Client-side profiling captures device, connection, behaviour and agentic signals, with request-layer inspection when deployed on your CDN. A real-time decisioning engine assesses every interaction against the intent and shape of the whole journey, then decides: pass, step up, or refuse.

Coverage

• Darwinium Deploys via:
  • Websites: JavaScript profiling on browser
  • Mobile Apps: Android, iOS and React Native SDKs
  • CDN: protection at the request layer, including backend and MCP server calls with Edge workers
  • API: direct risk assessment request, full response data returned
• Digital Profiling collects:
  • Device: identifier token, crypto hash for copy protection, signature for persistence and recognition leniency, forensics for integrity and tampering checks
  • Connection and location: layered technologies for consistency, lookups for context of type, provider, location, proxy and VPN
  • Behavioural biometrics: signatures simplify and cluster behaviour comparisons, touch, mouse, keystroke, sensors for artificial conditions
  • Identity: Resolving person behind the application, DarwiniumID
• Agentic Profiling
  • Intent: every step and tool call scored against the shape of legitimate traffic
  • Detection and classification: declared and undeclared automation, correlated across device, network, timing, behaviour and journey
  • Agent authentication: cryptographic agent signatures validated at the edge, allow-listing by agent
  • MCP and tool calls: JSON-RPC parsed at the edge, tool calls and the human checkout as one journey
• Real Time Decision Engine: Handling comparisons and returning risk assessment, as configuration you version and deploy
  • Features: remember history, varied timeframes, statistics for modelling
  • Rulesets and signals: human readable signals for justification, control over outcomes
  • Models: scores, ML models, linear scorecards
  • Declarative configuration: journey and decisioning versioned together, tested before release, promoted between environments, rolled back, audited
• Feedback Loop: Getting confirmed outcomes back into detection
  • Labels: marking outcomes, keeping lists, binding attributes, model feedback data
  • Update API: revise or enrich an event after it has been processed
• Inline request intervention: Using edge to perform inline actions at the request layer, live decisions without needing backend changes
  • Terminate: refuse high risk sessions instantly at the edge before they cause expense on backend services
  • Redirect: change the steps or order of the journey
  • Speedbump: proof of work that makes bots and scripted traffic uneconomical
  • Modify content: adjust user experience, dynamic messages, automatically insert profiling tags
• API orchestration: To consume enrichment data, notify an external service, or facilitate a challenge
  • Snippets marketplace: connect to third party tools using prebuilt templates
  • CallURL: call any custom endpoint, defining request structure and mapping of the response into Darwinium
• Investigations portal: Web application for investigating and configuring Darwinium
  • Reporting and dashboards: see important metrics and trends at a glance
  • Investigations view: search and simulate over all previous events
  • Behavioural Identity view: perform link analysis between identifiers
  • Incident management: group and work incidents into queues
• Data egress
  • Analytics environments: Facilitating data consumption into S3, Databricks, Snowflake
• Privacy architecture: Darwinium never has to process or store even encrypted PII; stays in your domain
  • Bring your own storage: event data in your own bucket, in your region
  • In browser decryption: personal data decrypted only within privileged investigator's browser, never on a Darwinium server

More detail: Introduction To Darwinium, Architectural Overview, Quick Start

Use Cases

The same profiling and the same data serve every use case, so adding one is a change of policy rather than a new integration.

Account security

• Account takeover
• Credential stuffing and lateral movement after login
• Stolen and spoofed identities

Automation and abuse

• Bots, headless browsers and scripted traffic
• AI agents, both the customer's and the attacker's
• Click farms and device farms
• API abuse and business logic abuse
• Scraping and content spam

Onboarding and accounts

• Fake accounts and repeat registrations
• Bonus and promotion abuse
• Loyalty and points theft

Banking

• Money mules
• Scam detection, including coercion and remote access

Applied across eCommerce, marketplaces, gaming and gambling, fintech, retail banking and airlines.

Deployment

Darwinium is deployed into infrastructure you already own.
Deployment methods can be mixed on a single journey, so a web checkout protected at the CDN and a backend payment call made over the API are treated as the same session by the same engine.

CDN Deployment

Darwinium runs as serverless compute inside your own CDN account.

Supported CDNS:

• Cloudflare (Workers)
• AWS CloudFront (Lambdas)
• Akamai Linode

Multiple CDN targets can be used at the same time.

Covers any request through the CDN, including backend APIs and MCP server calls. Request and response are both available for inspection.

Connection based profiling is always received from the CDN, regardless of the client side.

Request and response insertion

• Insert JS profiling dynamically, rather than needing to manually add tag to every page
• Request header enrichment: add Darwinium identifiers, signals and scores to the request before it
  reaches origin, so existing backend code can act on them
• Response body personalisation: insert or modify content on the way back, for example a scam warning
  worded for what was detected, or a refusal with more specific information

More detail: Deployment Targets, Edge Integration Technical Design, Cloudflare Deployment, CloudFront Deployment, Akamai Deployment

Web and Mobile Profiling

Client side profiling on the channel of choice.

• Web: JavaScript profiling, inserted by the CDN or added to the page as a tag
  • Where endpoints already run through the CDN, journey coverage needs no application change
• Mobile: Android, iOS and React Native SDKs

More detail: Tags Deployment, Mobile SDK Deployment, Mobile SDK Reference

Event API

Backend initiated, server to server risk assessment.

• Full response data returned, including signals, scores and profiling attributes
• The endpoint can be deployed into your own cloud account, so data is encrypted before it reaches Darwinium on backend API path too

More detail: Event API, Setting up API Outpost, Setting up certificates & Access

Identity

"Is this the same person, presented slightly differently?"

The details a customer supplies are the easiest thing for a fraudster to vary, and exact matching misses
every variation.

• Phonetic name matching, so names that sound alike encode the same ("Mikhail" and "Michael")
• Non-Latin scripts are romanised first
• Applies to the username part of an email address
• Runs at the edge in real time
• Identifiers seen in one session are linked to those seen in another, building shared history across
  account, device and phone number

A fuzzy identity signature, consolidating identity attributes the same way device and behaviour are
consolidated, is in development.

More detail: Linkage, Attribute Reference*

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 and Similarity

Signatures are Darwinium's approach to probabilistic identification.

Token based identifiers are increasingly likely to be deleted 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 the
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.

Device integrity, from the mobile SDK:

• Rooted and jailbroken devices, and the tooling used to do it
• Emulators, custom ROMs, test builds and debug bridge
• Recent factory reset, out of date security patch
• App cloning and secondary user profiles
• Side loaded apps and tampered app hash

Device integrity, from web profiling:

• Browser extensions, including those running in other tabs
• Safari private browsing
• Browser automation frameworks (Puppeteer, Selenium)
• Remote access software on the machine (TeamViewer, AnyDesk, VNC, RDP)

Use cases: Device

• Bots: emulated devices, automation frameworks driving the browser
• Device farms: rooted phones, cloned apps, many accounts on one device
• Scams: remote access software active during a transfer
• Trust: same device signature, no integrity flags

More detail: Device Signals, SDK Device Attributes, Root & Jailbreak Detection

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 signature

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.

Use cases: Behaviour Signatures

• Bots: identical behaviour signatures
• Abuse: spike in new similar behaviour signature cluster
• Trust: close to the customer's normal behaviour signature

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)

Use cases: Keyboard

• Bots: regular cadence, quick timing
• Abuse: paste usage in unusual fields, tab overuse
• Trust: cadence within their norm, natural cadence, often autofill

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
• Click position

Use cases: Mouse

• Bots: quick movement, no curvature, no movement
• Click farms and abuse: 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)

Use cases: Touch

• Bots: not a real tap profile
• Abuse: quick timing
• Trust: swipe profile looks the same

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

Use cases: Sensors

• Virtual machines: no variance or unusual sensor readings
• Scams: on phone, flat on table
• Location: inference

More detail: Behavioural Biometrics Data, Behavioral Biometrics Setup, Key Input Field Contexts

Connection and Location

"How is the user connected to the internet, is it normal or does it try 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 and headers
• Multiple ways of inferring IP for consistency (PRIMARY, CDN inferred, HTTPS, WebRTC, forwarding, DNS)
• IP context lookups for type, location, details
• Proxy and VPN detection through packet inspection, returned as a probability
• Datacenter and residential proxy detection
• HTML/GPS geolocation for more precise location
• Mock location, and GPS country against IP country

Use cases: Connection

• Bots: datacenter connections at volume
• Account takeover: connection masking, location contradicting the account's history
• Abuse: sanctioned or unexpected countries

More detail: Connection Signals, IP Addresses

Agentic Detection

"Is this a human, an agent acting for one, or automation working against you?"

AI agents browse, compare and buy on a customer's behalf. Some announce themselves and some do not, and the same tooling serves a shopping assistant and a credential stuffing run. Blocking all automation now means turning away your own customers, so the question moves from "is this a bot?" to "is this agent authorised, and is what it is doing right now consistent with that?"

Agentic Use Cases:

• Scraping: systematic enumeration at uniform cadence, no engagement signals
• Credential and card testing: a burst of cart and payment calls, near zero time between steps
• Business logic abuse: rapid add to cart loops on limited stock, velocity far outside normal
• Hijacked or prompt-injected agent: the signature is valid, but the journey diverges from the declared mandate
• Trust: a signed agent, a journey consistent with its stated intent, no friction applied

Detection and classification

Declared and undeclared automation are both detected. User agent strings are not relied on, because they are trivially spoofed. Some AI browsers announce themselves with a distinct user agent, others present as regular Chrome.

Signals are correlated across five layers:

• Device: automation stacks and agent tooling, headless browsers, contradictions between user agent hints and the observable environment
• Network: header structure against the claimed browser family, TLS and HTTP traits of scripted clients, proxy rotation, datacenter origin, fetch order anomalies such as hitting JSON endpoints with no page context
• Timing: millisecond navigation gaps, low variance between requests, activity with unusual rhythm
• Behaviour: absent or synthetic mouse movement, uniform keystroke timing, repeated click positions,
  form fills with no preceding interaction
• Journey: shortcutting to high value endpoints, actions submitted with no prior page flow, post-login behaviour that does not match the customer

Hybrid sessions are common and are handled as one journey: an agent navigates to the login page, the person authenticates, then the agent drives everything after it. Binding the session to that moment of human proof, and stepping up again when the agent reaches a sensitive action, is a policy decision rather than a code change.

Agent Signature

Emerging standards let an agent cryptographically sign its requests. Darwinium can observe and validate these HTTP message signatures at the edge.

• Surfaces whether a signature is present, and whether it validated
• Flags replayed nonces, expired signatures and public keys that cannot be retrieved
• The agent's key is a listable value, so an allow list of trusted agents is a rule rather than a config file
• One primitive covers several schemes. web-bot-auth, Visa Trusted Agent Protocol and Mastercard Agent Pay are all built on the same RFC 9421 signature pattern, so a single integration carries over to whichever your partners mandate next

Traffic that behaves like an agent but announces nothing can be made to prove what it is, using a speedbump or a redirect challenge directly.

MCP and tool calls

JSON-RPC is a first class payload type at the edge, so an MCP server is governed by the same policy engine as the website in front of it.

• Parse JSON-RPC requests and responses, and extract any tool calling argument or response field with JSONPath, configured in the portal with no backend code change
• Ordered tool calls and the eventual human checkout stitch into a single journey, with payloads such as line items, quantities and totals visible on every call

Decisioning

A workflow is the whole definition of what Darwinium does on a journey: which steps are assessed, what profiling runs at each one, and the logic that decides the outcome. Three parts do the deciding and are meant to be used together. Features carry the history an identifier has built up, rules turn that into human readable signals, and models turn the picture into scores.

Assessments run in parallel. Best practice flagship policies are available on day one, so a new deployment starts with detection that already works. The workflow is then changed by the team that owns the risk, in the portal or in Python, not on an engineering release cycle.

Features

Darwinium contains an integrated real-time feature store.

That supports decisions to be 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

Journey shape is also available as a feature: the probability of the last transition, of the sequence, and of reaching a step within a number of transitions or an elapsed time.

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

More detail: Features Overview, Features Editor, Journey Model

Rulesets and 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 a linear score
• can reference earlier steps in the same session

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

More detail: Decisioning Overview, Rules and Signals, Package dwn_ext_decision

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
• readable against the distribution they came from, using percentiles
• used to influence overall decision recommendation

A challenger model can run alongside the live one and be compared before it takes over.

More detail: Models and Scores, Machine Learning Execution, Model Scoring and Percentiles

Decisioning defined Declaritively

A workflow is not settings in a database. The journey definition and the decisioning inside it are declarative files held in the node's own repository, edited in the portal workflow editor or as code, and can be deployed or rolled back with full git based version control.

• Every change recorded, so who changed what is recoverable
• Test and debug a change before it goes live
• Deploy and undeploy, promote from a test node to production, and roll back to the version before
• Single sign-on, with roles controlling who can see and change what, per node![Image](https://fil
• Deploy and undeploy, promote from a test node to production, and roll back to the version before
• Single sign-on, with roles controlling who can see and change what, per node

More detail: Journey Lifecycle Overview, Continuous Deployment Overview, Debugging Journeys, Repository Access, Establishing SSO, Configuring Roles & Access

Feedback Loop

Detection only stays accurate if confirmed outcomes can be fed back into the system for continuous tuning and optimisation.
Darwinium has two mechanisms do that:

• labels attach a known good or bad outcome to identifier(s)
• Update API revises attribute on an event after the fact

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 (block, pass, review, watch)
• ML model feedback data

Labels can carry a lookback period, and so a TTL.

Labels can be applied:

• Manually in the Darwinium Portal, including multi-select and batch labelling
• Automatically via ruleset logic
• In bulk via API call

Example label use cases:

• Device binding: apply a label to an account and device pair when authenticated, do not step up again
• Marking fraud: mark a device during an investigation as being used for a confirmed account takeover
• VIP customers: automatically apply a label on a customer token when over a threshold of deposits; offer more generous promotions

More detail: Labels, Label API

Update API

Retrospectively update the details of an event that has already been processed.

Example UpdateAPI use cases:

• Add a customer number to a registration event once it is known
• Change an event type from payment attempt to payment successful
• Apply labels retroactively when an investigation closes
• Trigger update driven rulesets and downstream workflows

More detail: Update API

Intervention

Darwinium can act on its own decision at the edge, at the request layer, without backend changes.

Speedbump

• Issues a unique proof of work algorithm per request, deliberately avoiding SHA and AES so specialised hardware gains no advantage
• False positive user: sees a small load delay while browser performs proof of work, BUT only have to wait. No annoying captcha or puzzle.
• High frequency bot: has to perform the compute thousands of times over, raising the cost of the operation
• Headless browsers cannot solve it
• Produces CHALLENGE_PASSED, CHALLENGE_FAILED and CHALLENGE_INVALID, queryable in investigations

Proxy actions drop or redirect traffic at the edge. Put Darwinium in front of compute heavy endpoints, (eg. search), and the abuse is blocked at the Edge, without backend absorbing the cost to service the requests.

More detail: Actioning on Darwinium, Rules: Proxy Actions

Orchestration

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

Can occur always, or conditionally based on a logical criteria. Prebuilt template 'snippet' integrations in the Darwinium marketplace speed up time to setup common integrations.

Orchestrate page content

Choose what, where and how to insert additional content onto the page (edge deployment only).

Examples:

• Insert Darwinium JS profiling into the page head
• Insert bot captcha onto the page
• Insert conditional, tailored scam warning text

Orchestrate data

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

Examples:

• Email risk intelligence lookup, called only for borderline cases so a per lookup cost is spent where it
  changes the answer
• Phone number SIM swap lookup
• Push Darwinium event data to an internal data store or collector

Orchestrate alerts and cases

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

Examples:

• Populate a case management queue, with event details and risk reason
• Trigger an email alert or Slack notification, with details of the event

More detail: Call URL, Injection and Extraction Menu

Privacy Architecture

Darwinium never has to store or process customer PII, in clear or encrypted form. It stays within your own domain. Bring your own storage is a platform wide principle, not an option on one feature.

• Event data is written to a bucket you own, in the region you choose, and served from that region
• Personal data is encrypted at the point of capture, in your CDN or your own cloud account (API outpost), before it reaches Darwinium
• A second copy is anonymised with a one way hash. It is searchable for an exact value, but the original cannot be recovered from it
• In the portal, personal data is decrypted in the browser of a user holding the Read PII permission, with a per event key rather than a universal one
• Everyone else, including Darwinium staff, sees the anonymised form
• Keys rotate on a schedule you set, and every access to personal data is written to an audit trail
• Retention, TTL and GDPR deletion are configurable

More detail: BYO S3 Event Storage Overview, S3 Storage Config, Backups & GDPR

Darwinium Investigations Portal

The Darwinium Portal is the web application for investigating events and configuring the platform.

Dashboards

Design charts and visuals for monitoring and visibility. Signals dashboards show what is firing and how often, with trends annotated by your own deployments.

Investigations view

Search and simulate conditions over all previously assessed data. Query syntax with a visual builder, saved views and templates, a journey view of a whole session, notes on events and CSV export.

Behavioural identity view

Graph analysis to link patterns and investigate fraud rings through link analysis.

Incident management

Native in-platform case review, with grouping, expiry, team and queue management, worklogs and an admin
performance view.

More detail: Portal Overview, Investigations Overview, Dashboards, Incident Management Introduction

Data Egress

Data scientists will want to analyse and model in their own environment. Darwinium supports egress of
event data into analytics stacks with no extra commercial implication. Darwinium schema updates are managed automatically. Personal data leaves in its anonymised form.

Supported destinations:

• AWS S3
• Databricks via AWS S3
• Snowflake via AWS S3, or via GCS
• Jupyter notebook, with a Python library for querying events directly in platform (with memory/compute limits)

More detail: Exporting data to AWS S3, Exporting data to Databricks, Exporting data to Snowflake

* Attribute Reference needs a documentation
sign-in, which you get as a customer. Every other link on this page is open. See Access Gated Docs Links if you have an account and cannot get in.