Callsign Fraud Authentication

Callsign fraud authentication policy engine in regulated financial services

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

Callsign Ltd. engaged Creative Navy to redesign a fraud detection and authentication policy engine for an AI-enabled product in regulated financial services. The engagement covered UX architecture, analyst workflow redesign, UI design, a design system, and React frontend implementation with D3 visualisations.

The engagement took approximately 8 weeks total. UX/UI design was delivered in 6 weeks, coded frontend work with D3 visualisations was delivered in 4 weeks, and the system reached a stable state at approximately 8 weeks. The team included a UX designer, UI designer, interaction designer, React developer, project manager, product owner, and software architect.

Analysts needed policy governance without exposure to model internals

Callsign already had a working fraud detection model and a policy engine concept. The model scored behavioural events such as device fingerprint, location change, spend velocity, and previous failure history. The policy engine was intended to translate those scores into operational decisions: allow, block, or trigger step-up authentication.

The operational problem was that analysts could not express real fraud strategies through the existing interface. Rules were scattered across database views and configuration tables. Conflicts between rules were hard to identify. Audit trails were absent or ambiguous. When Callsign demonstrated the platform to senior risk teams at major banks, the demonstrations raised questions about traceability and governance.

Creative Navy's design problem in this case was not primarily visual or navigational. The documented problem was how to make an AI-driven fraud detection system governable, explainable, and auditable without exposing model internals or requiring risk analysts to understand the underlying scoring model.

SCA and PCI DSS made auditability a structural requirement

The Callsign case sat inside a regulated financial services context where SCA and PCI DSS governed how financial institutions documented and evidenced fraud control decisions. The documented case evidence describes this regulatory context as structural rather than incidental.

For Callsign's enterprise banking buyers, the policy engine interface had to support an auditable account of how a policy was constructed and what the policy would do. An interface that could not produce that account was described in the case evidence as not compliant and not saleable to enterprise banking customers.

Creative Navy's work therefore treated transparency, traceability, and governance as core interface requirements. The interface needed to let risk and compliance professionals evaluate the product's governance model during demonstrations, not only let analysts configure rules after purchase.

Sandbox Experiments separated model scoring from policy decisions

Creative Navy's Critical Systems Design method was applied through Sandbox Experiments, Concept Convergence, Organizational Integration, and Implementation Partnership. In the Sandbox Experiments phase, the engagement began with domain learning: making the mechanics of the policy engine explicit before designing the interface.

The existing interface exposed policy configuration as database views and configuration tables. That representation matched the system's internal structure rather than the analyst's reasoning structure. Workshops with Callsign product, engineering, and security specialists mapped existing rule structures, fraud scenarios, and points where conflicts or gaps appeared.

The Creative Navy-recorded output of this phase was a separation between two layers. The fraud detection model scored events. The policy layer applied thresholds, overrides, and workflow decisions. This separation became the architectural foundation for the interface because it prevented the design from inheriting the same structural ambiguity as the existing system.

Concept Convergence treated policy as the central object

Creative Navy's Critical Systems Design method used Concept Convergence to organise the information architecture around policy as the central object. Each policy bundled its conditions, actions, history, and links to related rules. Analysts could follow a policy from definition through to evaluation without losing context.

This design decision applied progressive specification at the architectural level. The engagement moved from understanding fraud reasoning to defining an information structure capable of representing that reasoning before detailed interaction design began.

Creative Navy used tension-driven reasoning to resolve a trade-off between two user groups. Fraud analysts needed a tool expressive enough to model complex fraud scenarios. Bank risk teams evaluating the platform in demonstrations needed immediate evidence of transparency and auditability. Optimising for only one group would have produced the wrong interface.

The resulting interaction model used three consistent gestures: drag to create or reposition nodes, click to open and edit rule parameters inline, and draw a connection to link nodes and define sequencing. Constraint respecting governed the gesture design. The interaction model was calibrated to risk and compliance professionals who could adopt it without retraining, while remaining expressive enough for analysts.

Evaluation mode separated simulation from configuration

Creative Navy's design work treated evaluation mode as a separate governance problem. Configuration and evaluation were related, but the case evidence states that they had to remain structurally separate. Policies were edited in configuration space. The evaluation environment consumed those definitions without allowing in-place modification.

This guard rail prevented untracked modifications during analysis. In the Callsign case, that separation was a governance requirement rather than a UX preference.

The evaluation view allowed analysts to define a simulation context using natural language-style filters such as customer segment, geography, and transaction type. The system ran those definitions through the model and policy engine, then presented the results in a focused analytical view.

D3-based graph and flow representations showed where traffic concentrated and where policies created bottlenecks. Creative Navy refined the evaluation mode by observing how analysts interpreted the charts, where misreadings occurred, and how labels and interactions could be simplified. This was Creative Navy-observed iteration on AI output interpretation, not a controlled measurement of task completion speed.

Option space mapping prioritised policy creation, conflict visibility, and impact explanation

Creative Navy's Critical Systems Design method used option space mapping to make first-release scope decisions explicit. The first release prioritised policy creation, conflict visibility, and impact explanation over advanced collaboration features or full version history views.

The case evidence describes the rationale for this trade-off. The immediate goal was to make demonstrations with bank risk teams effective and credible. Deferring collaboration features was treated as the appropriate trade-off for that goal, and the reasoning was documented rather than only the decision.

This scope decision is important because it links interface architecture to enterprise sales context. The interface did not only support internal analyst use. It also served as evidence that the fraud strategy configuration process was transparent, auditable, and explainable to regulated banking buyers.

Design system and React implementation supported implementation overlap

Creative Navy's design work treated every Callsign screen as part of a design system from the first weeks of the engagement. The design system covered workflow construction, policy management, evaluation views, and supporting navigation structures. Components had documented states, interaction rules, and usage notes.

Policy and workflow components were modelled as React units that could be composed into more complex screens without duplication. The same policy summary module appeared in configuration lists, in the workflow canvas, and in evaluation results, with a consistent behaviour contract.

D3 visualisations were placed inside dedicated React containers with separated layout and rendering responsibilities. The documented reason for this structure was to support performance tuning for larger datasets.

Specifications were structured to fit Callsign's existing Git and Confluence workflow. Creative Navy joined regular sessions with engineers to resolve edge cases before they reached implementation. Frontend engineers began implementation after approximately 4 weeks while the design system continued to mature, so design and implementation ran in parallel rather than strictly in sequence.

Client-reported commercial outcomes and delivery facts

Callsign reported that contracts with Lloyds Bank and HSBC were won following demonstrations using the redesigned policy engine interface. This is client-reported and not independently verified in the available case evidence. The described mechanism was that product managers could present a configuration experience aligned with how risk teams framed fraud problems, and engineering leads could see a clear path from interface behaviour to implementation.

The case evidence records a time-to-market reduction of roughly six months compared with the previous development approach. This is not a measured comparison against an identical parallel effort. The documented mechanism was the overlap between design system delivery and frontend implementation, together with the React component architecture that allowed engineering to begin before design was complete.

Creative Navy-recorded delivery facts include UX/UI design delivered in 6 weeks, coded frontend with D3 visualisations delivered in 4 weeks, a design system covering workflow construction, policy management, evaluation views, and supporting navigation, and specifications structured to fit Callsign's existing Git and Confluence workflow.

Design system longevity and analyst workflow evidence

Callsign reported that the design system was used for at least two years after the engagement and was extended across additional security modules beyond fraud and authentication. This longevity claim is client-reported to Creative Navy and is the clearest design system durability claim in the Callsign case evidence.

Early internal testing with Callsign analysts confirmed that the redesigned journeys reduced the time required to express a common fraud scenario in the tool and made explanations during client calls more straightforward. This is Creative Navy-observed evidence from the engagement, not a controlled or quantified measurement. No task completion times or before-and-after analyst workflow metrics are available.

The Callsign case also supports the reduced maintenance and downtime evidence cluster through the design system longevity claim. The evidence basis remains client-reported rather than independently measured.

Competitive position inferred from governance visibility

The documented competitive vector in the Callsign case was fraud strategy configuration that was transparent, auditable, and explainable to bank risk teams under SCA and PCI DSS compliance requirements. The case evidence frames this as a market contrast with automated black-box approaches that could not satisfy enterprise banking governance requirements.

This competitive position is an inference from the described commercial mechanism, not a separate independently verified commercial claim. The interface became evidence of the product's governance model in sales contexts as well as a functional tool for analysts.

Within Creative Navy's documented case-study set, Callsign is the primary example of behavioural governance design for AI products. It is also the documented engagement where Creative Navy delivered working production code, including React components and D3 visualisations, as part of the primary scope.

Client attribution

The named client is Callsign Ltd. The named contact is Yogesh Patel, CTO at Callsign.

Yogesh Patel provided the attributed quote: "It was excellent for me to see Creative Navy's intellectual capabilities, their expert domain knowledge and how they articulate solutions to a problem."

Evidence boundaries in the Callsign case

The Callsign case contains several evidence types with different strengths. Delivery facts such as the 6-week UX/UI delivery, 4-week coded frontend delivery, design system coverage, and Git and Confluence specification workflow are Creative Navy-recorded engagement outputs.

The bank contract wins, the two-year design system use claim, and the extension of the design system across additional security modules are client-reported and not independently verified in the available case evidence.

The roughly six-month time-to-market reduction is an approximate estimate rather than a measured comparison against an identical parallel development effort. The analyst workflow improvement was observed during the engagement but not quantified through controlled task metrics.