Release Notes 1.5.23

DateTime: 20th February 2026, 10:53 AEDT

Overview

This is one of our biggest releases. Two headline features lead the way:

• In Browser Decryption (IBD) enhances even further the approach to handling sensitive personal data in the portal, such that it only decrypts inside your browser; highest level of privacy posture.
• Speedbump adds invisible proof-of-work bot detection at the edge. Genuine users pass through in moments, while automated attacks face a steep computational cost that makes large-scale abuse impractical.

The tools you use every day to write and tune fraud logic have seen major work.

• Rules Editor V2 now includes a built-in language server that catches errors as you type and blocks builds when validation issues exist, so you stop discovering problems at runtime.
• Metaphone3 brings phonetic matching to identity resolution, linking names that sound alike but are spelled differently.
• A new quantile estimation, approximate velocity, and approximate distinct count features give you statistical context for your rules: is this value unusual, or just high?

For engine and data processing

• Update API direct-call support lets you enrich or reclassify events after initial processing, essential for "assume failure" patterns where outcomes aren't known upfront.
• Data export new destinations include Snowflake, Databricks, and directly to S3, so you can combine Darwinium signals with your own analytics stack.
• Profiling enhancements across iOS, Android, and web gets better emulator detection, VPN detection, and new biometric signals.

And on the Portal operations side

• Journey improvements means we now support cross-event dependencies and parallel flows
• Incident management gains worklogs and a performance view so fraud ops leads can track workload and throughput across the team.
• And dozens of portal UX improvements and bug fixes smooth out the day-to-day investigation experience.

In Browser Decryption

We already had strong posture for PII handling and treatment. A "bring your own bucket" approach ensures Darwinium does not store even encrypted PII data and the decryption service is performed on Edge workers or API outpost too.

In Browser Decryption (IBD) enhances even further the approach to handling sensitive personal data in the portal. With IBD enabled, personally identifiable information (PII) is encrypted end-to-end from point of capture within your CDN or API outpost and never exists in a decrypted form on our servers. Data stays encrypted at rest and in transit, and is only decrypted inside the browser on an authorized user. This Darwinium's handling is a major step forward for data privacy and compliance: sensitive customer data is protected end-to-end.

Decrypted Views Across the Portal

IBD now works consistently across all the key investigation and monitoring views in the portal:

• Investigation / Query View: search results and grid data
• Event Detail: individual event inspection
• Identifier View: identity lookups
• Incident Management: case queues and incident grids
• Entity Relationships: relationship graph widgets
• Journey View: step-by-step journey analysis
• Top-X Dashboards: high-level analytics and ranking views

Wherever you're working in the portal, decrypted PII is handled the same way: securely fetched and rendered client-side. You can also download your current query results directly from the browser, and exported data follows the same secure flow.

Key Management & Authentication

• Automatic key selection. A key digest attribute identifies which encryption key was used for a given piece of data, so the correct decryption key is always returned. Key rotation is seamless.
• Data Sovereignty. Data is saved directly by edge or API outpost to your region of choice. Data is made available to authenticated analysts through a CDN within this region, without crossing national boundaries.
• Controlled rollout. A new per-node feature flag lets teams enable IBD gradually across their deployment.

Speedbump - Bot Remediation

Speedbump is a new bot detection layer that uses proof-of-work challenges to slow down automated attacks. When suspicious activity is detected, the visitor's browser must solve a small computational puzzle before it can proceed. Genuine users will barely notice (the challenge completes in moments), but automated scripts and bot frameworks face a much higher cost per request, making large-scale attacks impractical.

How It Works

Speedbump sits at the edge and intercepts requests that your journey rules flag as suspicious. Here's the flow:

Key design points:

• Configurable difficulty: You control how hard the puzzle is and how many repetitions are required, so you can tune the cost for attackers without affecting legitimate users.
• Dynamic challenge logic: Speedbump does not use cryptographic primitives like SHA or AES, which are well supported by ASICs, and server hardware and puts mobile browsers at a disadvantage. Instead, each and every request issues its own unique proof-of-work algorithm, putting every browser at the same level.
• Headless browser resistance: Standard headless browsers cannot solve Speedbump challenges, making this an effective filter against automated tooling.

Signals & Attributes

Speedbump generates new signals and attributes that you can use directly in your journey rules and dashboards:

• Challenge results. Each challenge produces a clear outcome: CHALLENGE_PASSED, CHALLENGE_FAILED, or CHALLENGE_INVALID. You can branch your journey logic on these signals, for example blocking or stepping up authentication when a challenge fails.
• Speedbump attributes. New attributes capture challenge state and step progression, giving visibility into how challenges are performing across your traffic.
• Queryable in investigations. Speedbump events appear in the portal's investigation views, so your team can search, filter, and inspect challenge activity alongside regular journey data.

Rules Editor V2

Overview

The Rules Editor V2 has had major improvements, centred around a built-in language server that gives you real-time feedback as you write rules. Errors are now caught and highlighted as you type instead of at build time (or worse, at runtime), making rule authoring faster and more reliable.

Language Server Integration

The editor now includes an integrated language server that analyses your rules in real time. Errors and warnings appear inline as you work, so you can fix issues on the spot rather than hunting through build logs later.

What it catches:

• Invalid attribute types: referencing an attribute with the wrong type triggers an immediate warning
• Unavailable Attributes: in-line detection if an attribute is not populated where it is used, for instance information not being captured.
• Syntax errors and invalid values: malformed expressions and unsupported values are highlighted before they cause trouble

Critically, builds are now blocked when validation errors exist. It used to be possible to build and deploy rules that contained errors, which only surfaced as confusing "step not found" errors at runtime. The editor now won't let you build until the issues are resolved.

UX Improvements

Other usability improvements across the editor:

• Save on edit. After making a change to a rule, the change is persisted immediately, no chance of losing your work.
• Multi-line condition boxes. Condition expressions are no longer cramped into a single line; the editor supports multi-line editing with a CheckLabel helper for clearer readability.
• Common search UI. The search experience is now consistent across both the rules and features editors.
• Export includes analytics results. When exporting rules, you can now include analytics results alongside the rule definitions.
• Paste without existing rules. You can now paste rules into an empty editor. Previously at least one rule had to exist first.
• Auto-open condition popup. When creating a new group, the condition popup appears automatically so you can start writing straight away.
• Import compatibility. Importing rules from older versions (such as v1.5.22) no longer corrupts attribute names like nested custom attributes.
• Save reliability. We resolved a race condition that could cause saves to conflict or fail silently.
• Marketplace templates. The Darwinium Marketplace now includes template rules and feature sets that you can install directly from the Workflows screen. Choose a template, configure your parameters, and click install. Templates are cached locally, so updating to the latest version is a single click.

Phonetic Matching (Metaphone3)

Metaphone3 is a phonetic encoding algorithm that converts names and text into sound-based codes. If two names sound similar but are spelled differently, they produce the same code. This is especially useful for identity resolution when you're dealing with users across different languages and regions where name spellings vary widely.

How It Helps

• Better identity clustering. Different spellings of the same name produce the same phonetic code, so identities that would otherwise look unrelated get linked. For example, "Mikhail" and "Michael" generate a matching code, catching connections that exact-match logic would miss.
• Works across languages. Unicode characters (accented or non-Latin characters) are automatically romanised before encoding, so names in different scripts are still matched accurately.
• Smart email handling. Only the username portion of an email address is encoded (not the domain), so you can match similar usernames across different providers.
• New metaphone attributes. Dedicated phonetic attributes are available for use in your rules and features.
• Real-time at the edge. Metaphone encoding runs at the edge, so phonetic matching happens in real time as events are processed. No batch delay.

Quantiles & Global Policy

Quantile estimation is now available for global features and journey models. Quantiles tell you where a particular value sits within the overall distribution: is this device count in the top 1% of all users, or comfortably in the middle? This context is essential for writing effective fraud rules, because it helps you distinguish genuinely unusual behaviour from values that just look high in isolation. Quantile distributions are visible directly in the portal, so you can inspect how values are spread before deciding on thresholds.

Quantile support was previously behind a feature flag. It's now enabled by default for all global policy features, and feature calculations are scoped per organisation so your distributions reflect your own traffic, not the platform as a whole.

Approximate Velocity & Distinct Count

Two new feature types work at global policy scope:

• Approximate velocity measures how quickly a value is changing over a given time window. For example, you could track how fast a particular account is accumulating new devices or new IP addresses. A sudden spike in velocity is often a strong signal, whether from a compromised account or an automated attack.
• Approximate distinct count tracks how many unique values have been seen for a given attribute. For instance, how many unique payment methods has this identity used in the last 30 days? A high distinct count can flag account-sharing or fraud rings.

Both feature types now support map keys in attributes, which lets you run these calculations at a more granular level, for example tracking distinct counts broken down by a specific attribute key.

These are approximate calculations by design, which allows them to run efficiently at scale without the overhead of exact counting. The trade-off in precision is minimal, and the performance benefit means these features work reliably even on high-volume global policies.

Incident Management

Incident management now has better tracking, accountability, and operational visibility, aimed at fraud operations teams who need clear audit trails and insight into how work is distributed.

Worklogs

Analysts can now log time spent on each incident directly within the incident view. Team leads get a clear picture of workload distribution: where time is being spent, which incident types take the longest, and whether the team has capacity. If you're managing a growing fraud ops team, worklogs make capacity planning practical.

Admin Performance View

A new admin performance view provides metrics across the incident queue: how many incidents each analyst has handled, average resolution times, and overall throughput. Useful for larger teams where tracking individual contribution and spotting bottlenecks is hard without a dedicated view.

Other Improvements

• Tighter closure controls. Only the assigned user can now close an incident. Previously any user could close any incident, which made it harder to maintain clear ownership.
• Queue and template fixes. Saved queue configurations and template grid attributes now persist correctly.
• Clearer error messages. Error messages throughout incident management are now more specific and actionable.
• Reject option restored. The reject option for events during incident review is available again, and the final review status now updates correctly when an incident is closed.

Data Export

You can now send Darwinium event data directly to the analytics platform your team already uses, combining fraud signals with your own business data for deeper analysis without building custom pipelines.

Supported Destinations

You can now choose from the following export destinations, selectable from a dropdown in the portal:

• Snowflake (via S3 or GCS): event data flows through S3 or GCS into your Snowflake warehouse, ready for querying and reporting
• Databricks (via S3): for teams using Databricks for data science and ML workflows, event data routes into your Databricks environment
• S3: export directly to S3 as a standalone destination, or use it as a staging layer for other tools

Export performance is also improved. S3 writes now happen asynchronously, so exports are faster and less likely to be slow during high-traffic periods.

Journey Improvements

Journeys are now more flexible, with support for more complex user flows and better performance under load. These improvements help you model real-world behaviour where users take multiple paths or revisit steps during a session.

Cross-Event Dependencies

Journeys can now reference events across different journey steps when session ties have been established. Rules at a given step used to be limited to data from that step alone. Now you can write rules that take into account a user's full session history, for example referencing what happened at login when evaluating a payment step later in the same session. This is important for catching fraud patterns that only become visible across multiple interactions.

Journey Improvements

Several improvements to how journeys handle transitions and parallel flows:

• Journey transition performance. Journey transition feature evaluation now uses early-out optimisation and cached transition sketches, which reduces processing time. If you have high-traffic journeys with many transitions, expect faster evaluation under load.
• Multiple journeys per identifier. Multiple journeys can now share the same journey ID identifier. This is useful when you have parallel flows for the same user, for example a user going through both an onboarding journey and a verification journey at the same time. Previously the journey ID could only reference a single journey.
• Synchronous ID writes. Journey ID writes are now synchronous, so downstream steps always see the most up-to-date journey state. This eliminates a class of timing-related inconsistencies under heavy load.
• Post-deploy webhook. A new post-deploy webhook triggers external processes automatically when a journey is deployed, useful for CI/CD pipelines, notifications, or downstream workflows.

Update API

See: https://docs.darwinium.com/docs/update-api

The Update API can now be called directly, so you can enrich or reclassify events after they've been initially processed. Modify attributes, run workflows, and manage labels on existing events: essential for scenarios where the final outcome isn't known when the event is first received.

For example, when a user completes a login, the initial event might be recorded as account_login. Once authentication succeeds, you can call the Update API to change it to account_login_success, ensuring your risk models and reporting reflect the actual outcome rather than an incomplete state.

Update API use cases

• Reclassify events: change event types or attributes after the fact (e.g., marking a login as successful once authentication completes)
• Enrich events: add data that's only available post-processing, such as customer tokens issued after account creation
• Apply labels retroactively: label device + identity combinations based on outcomes, not just initial signals
• Trigger workflows: run conditional rulesets against updated events to cascade changes through your rules

Workflow Editor Support

The portal's workflow editor now supports event updates natively. You can configure rulesets that execute when an event is updated, applying labels, adjusting attributes, or triggering downstream logic based on the new information. Update-driven workflows can be built entirely within the portal, with no external orchestration needed.

Device Profiling & SDKs

Device profiling across web, iOS, and Android has been improved with richer signals, better detection accuracy, and new capabilities. The result is stronger device fingerprinting and more reliable fraud signals for your rules.

iOS SDK

The iOS SDK can now detect whether FaceID or TouchID is available on the device. This is a useful signal for device authenticity checks: a device claiming to be a recent iPhone but reporting no biometric hardware may warrant closer inspection.

New survival model attributes capture boot time patterns and timezone data. These help identify devices that have been recently reset or are behaving inconsistently with their claimed location, both of which can indicate device spoofing.

Android SDK

This release focuses on reliability and accuracy for the Android SDK:

• Language detection. The all_languages attribute now returns values correctly.
• WiFi attribute stability. WiFi-related attributes are now consistent across repeated reads, eliminating intermittent fluctuations that could affect fingerprint matching.
• Screen orientation. Orientation reporting now works across more device types.
• Emulator detection. Resolved a false positive where certain real devices (specific manufacturer models) were flagged as emulators.
• Blob handling. When an empty blob is sent, the has(profiling.device.signals,"EMPTY_PROFILING_BLOB") signal now fires correctly. Before this fix, the condition could go unreported, meaning certain automation detection rules wouldn't trigger.

VPN Detection

VPN detection profiling.vpn_probability is now more accurate at identifying users connecting through VPN services. VPN usage isn't always malicious, but knowing when it's present is an important input for fraud rules, especially combined with other signals like geolocation mismatches.

Device Signature Debugging

A new sidebar panel in the portal lets you inspect device signature details in a human-readable format. Understanding why a particular device was flagged, or how its fingerprint was constructed, used to require manual decoding. You can now expand the signature breakdown directly in the investigation view, which speeds up device-related investigations.

Other Improvements

• Browser extension detection. Extension detection now works reliably across tabs and window types. Previously results could be inconsistent when users navigated between windows, meaning some extensions went undetected.
• Safari private browsing. Detection of Safari private browsing mode has been improved, providing a more reliable signal for sessions where users are limiting browser storage.
• Profiling handle labelling. Profiling handles can now be labelled at the edge for easier organisation across your deployment.
• Mobile behavioural biometrics. Touch and mouse biometric signal collection for mobile events is improved, resolving an issue where mouse-type signals could incorrectly appear in mobile contexts.

Portal & Investigation UX

Dozens of improvements to the portal experience, from faster grid loading to better search and more useful documentation links. Small things individually, but together they make a real difference to daily workflow. This section covers the investigation view, signals dashboards, search and templates, and help documentation.

Investigation View

The investigation page has seen the most attention this release, with fixes across the grid, sidebar, and layout:

• Dynamic grid refresh. The events grid now refreshes automatically when you run a new query, and results update as you type in the search bar. No more manually triggering refreshes.
• Add fields from sidebar. You can now add a field directly as a column in your table from the sidebar filter menu, without navigating away.
• Scrolling fixed across all views. Resolved scrolling issues in the investigation grid, identifier view, and label view. Panels that were previously unscrollable now behave as expected.
• Virtual columns reliability. Virtual columns in the investigations table now load attributes correctly and are more predictable to work with.
• Default time range corrected. The investigation page now defaults to the last day of data, as intended. Previously the default range could be incorrect, leading to empty results on first load.
• Sidebar and layout fixes. The event detail sidebar is fully functional again, and expanding the left pane no longer cuts off investigation page content.
• Behavioural graph improvements. Labels no longer overflow in the Behavioural Identifier Graph, and the graph no longer gets compressed when certain identifiers are included or excluded.
• Stable page state. The page no longer resets unexpectedly when columns are updated alongside an invalid query. Time filters now use the correct reference time rather than page load time.

Dashboards

• Custom aggregates. You can now define custom aggregate columns in the signals dashboard. Compute a statistic at the rule, step, or journey level, then apply custom arithmetic and formatting using Jinja templates. Useful for calculating rates, sums, or ratios directly in the dashboard without exporting data. See https://docs.darwinium.com/docs/signals-dashboard
• Scrollbars added. Both vertical and horizontal scrollbars are now present. No more hidden off-screen content in large dashboards.
• Tooltip display fixed. Chart tooltips now show the correct values instead of displaying as [object Object].
• Git annotations on time series. Time series graphs now support optional annotations from git, letting you correlate signal changes with specific deployments.
• Better error reporting. When server-side issues occur, the dashboard now surfaces clear error messages rather than silently failing.

Search & Templates

• "Copy Value" restored. The right-click context menu once again includes the "Copy Value" option.
• "IS NOT NULL" operator. You can now use the "IS NOT NULL" query operator when searching identities, useful for finding all records where a particular field has any value.
• Search button reliability. The search query button now works consistently, resolving an intermittent issue where clicks were not triggering the expected search.
• Templates save reliably. Both search templates and query view templates now always save.
• Query download. You can now download results for your current query directly from the investigation view, with 1000 row limit lifted.

Help & Documentation

• Page-specific help links. Every portal page now links directly to its relevant documentation section, so you get context-sensitive help rather than landing at the top of the docs site.
• Help button moved to top level. The Help link is now in the top-level navigation and renamed Documentation.
• Broken links fixed. Documentation links from the investigation and labels sections now point to the correct pages instead of returning 404 errors.

Other Portal Improvements

• Organisation name editing. Administrators can now change their organisation name without contacting support.
• OTP reset for superadmins. Superadmins can now reset a user's one-time password directly.
• National ID formatting. National ID input values are now properly formatted in the portal for easier reading.
• Label modal improvements. The add label modal has been cleaned up and fixed.
• Superadmin save fix. Resolved an issue where settings in the superadmin menu could only be saved once per session.

Infrastructure & Deployment

Deployment reliability, cluster management, and infrastructure configuration all see improvements in this release. If you manage your own deployment, these changes mean fewer false alarms, better visibility into what's running, and easier day-to-day cluster operations.

Akamai & Linode

• K8s control plane upgrades from the portal. A new button lets you upgrade the Kubernetes control plane for your Linode clusters directly from the UI, removing the need for external tooling.
• Out-of-date cluster notifications. The portal now alerts you when a cluster is running a version behind the current release.
• Editable min/max node counts. You can now adjust minimum and maximum node counts from the cluster configuration screen, for easier scaling as traffic demands change.
• Targeted redeploy. You can now redeploy specific clusters without affecting others. Useful when you need to update one environment without touching the rest.
• Deployed version visible in the UI. The portal now shows which version is currently deployed on each Linode cluster.
• Nginx-ingress for Linode-only deployments. Linode-only deployments now support nginx-ingress, broadening supported deployment configurations.
• Edgeworker forwarding to Linode. Akamai edgeworkers can now forward requests directly to Linode origins, improving routing flexibility.
• Configuration and template fixes. We resolved several issues with Akamai configuration templates, including missing server entries, incorrect rule template formats, and optional fields appearing where they shouldn't. Deployments should need fewer manual corrections.

Deployment UX

• Accurate build and deployment status. Fixed several cases where successful deployments were incorrectly shown as failed in the portal. The status you see now reflects what actually happened, regardless of deployment target.
• Stuck builds resolved. An edge case where builds could get stuck when the top record was missing a job ID has been fixed. Builds now recover gracefully.
• Cloudflare multi-zone support. Cloudflare deployments now support multiple build targets sharing the same zone ID, important for teams managing several properties under a single Cloudflare zone.
• Cloudflare memory improvements. Optimised memory usage for Cloudflare workers to prevent resource limit issues during high-traffic periods.
• Preflight request handling. CORS preflight requests are now handled correctly at the edge, resolving cross-origin issues that could prevent the profiling script from loading on certain configurations.
• Stability fixes. Resolved a content server crash and a memory leak in the data processing layer.

New Attributes

Identity & Transaction

Speedbump

Phonetic Matching

Labelable Attributes

The following can now be labelled

Features & Scoring

Note: "Trust Score" attributes have been renamed to "Risk Score" across the platform for clarity. There is no functional change; the underlying logic and calculations remain the same. If you reference Trust Score attributes in existing rules, they will need to be updated to use the new Risk Score name.

Other Fixes

Alongside the features above, this release includes a broad set of bug fixes and stability improvements.

• Journey language server: resolved crashes, casing errors, and missing validation for duplicate journey names and debugger events
• Rules validation: improved handling of e164_number attributes, analytics conditions, and Speedbump event_type actions
• Portal UI: corrected cookie age type handling, string label casing, proxy status display, instance_id population, and pre-upgrade signal visibility
• Copilot: resolved crashes on journey transition probabilities, and restored functionality on signals/attributes pages
• Device & profiling: fixes for GEO_DISABLED signal generation, MX record lookup, profiling handle null checks, challenge retry loops, event ordering, split-profiling keybio, and homepage profiling on redirects
• Composite queries: resolved several issues with composite identifiers and checkLabel in queries and dashboard conditions
• Search & grid: IPv6 address search, profiling column display, grid attribute rendering, and ipinfo.coordinate queries
• Update API: better error responses for invalid identifiers, and correct event_type handling on prior events
• Akamai/Cloudflare: resolved deploy loops, edgeworker forwarding, Cloudflare log noise, and profiling request repetition counts
• Snowflake export: resolved missing events when using GCS as a staging layer