We started by making the mechanics of the policy engine explicit through domain learning. Policies in this context combine conditions on behavioural indicators such as device fingerprint, location change, spend velocity and previous failure history with outcomes such as allow, block or trigger step up authentication. The existing interface exposed these rules as database views and configuration tables. It did not match how analysts reason about fraud patterns or how they explain decisions to internal audit teams.

Through workshops with Callsign product, engineering and security specialists during Sandbox Experiments we mapped the existing rule structures, the fraud scenarios they needed to cover and the points where conflicts or gaps appeared. This mapping exercise led to a clear separation between the fraud detection model that scores events and the policy layer that applies thresholds, overrides and workflow decisions. The work became a piece of UX design for AI systems where the interface controls how model outputs flow into real world actions.

From there we defined an information architecture for enterprise security that treated a policy as the central object. Each policy bundles its conditions, actions, history and links to related rules. Analysts can follow a policy from definition through to evaluation without leaving context. Decisions are recorded in a way that supports audit review and regulatory checks related to SCA, PCI DSS and internal governance. We validated early versions of this structure with Callsign teams using concise scenarios rather than abstract diagrams, and adjusted based on their feedback.

With the architecture in place, we redesigned analyst journeys to reflect how fraud teams actually think through a case. The previous experience forced users to jump between configuration screens, reference documents and data tables when they wanted to adjust a single rule. We replaced this with a policy centric flow. Analysts identify a scenario, open the relevant policy set, adjust conditions in context and immediately see where in the workflow the change applies.

The core interaction concept was a three gesture model designed for interaction design for fraud analysts. Analysts drag to create or reposition nodes in the workflow, click to open and edit rule parameters inline and draw a connection to link nodes and define sequencing. These gestures are consistent across the tool, which keeps learning effort low for users who come from risk or compliance rather than product backgrounds.

We also had to make scope trade offs through tension-driven reasoning. For the first release we prioritised policy creation, conflict visibility and impact explanation over advanced collaboration features or full version history views. This decision reflected the immediate goal of making demos with risk and security teams at large banks effective and credible. Early internal testing with Callsign analysts confirmed that the new journeys reduced the time it took to express a common fraud scenario in the tool and made explanations during client calls more straightforward.

Configuration alone was not enough. Callsign needed a way for analysts and bank stakeholders to understand what a given set of policies would do in realistic scenarios. We created an evaluation mode where users define a simulation context using natural language style filters such as customer segment, geography or transaction type. The system then runs these settings through the fraud detection model and policy engine and presents the results in a focused analytical view.

The evaluation view is central to user experience for risk management tools because it closes the loop between configuration and impact. Analysts can see how often a scenario would lead to automatic approval, step up authentication or blocking, and can check whether high risk cases would slip through. To make this interpretable we relied on data visualisation for banking systems implemented with D Three, using graph and flow representations that highlight where traffic concentrates and where policies create bottlenecks.

We kept the relationship between configuration and evaluation very clear. Policies are always edited in the configuration space, and the evaluation environment consumes those definitions without letting users change them in place. This guard rail avoids untracked modifications during analysis. We used evidence based UX for AI to refine the evaluation flow, observing how analysts interpreted the charts and where misreadings occurred, then simplifying labels and interactions accordingly. The result is a controlled but flexible loop where analysts can test, adjust and justify policy strategies without exposing model internals.

From the first weeks we treated every screen as part of a design system rather than a one off artifact during Concept Convergence. The system covers workflow construction, policy management, evaluation views and supporting navigation structures. Each component has documented states, interaction rules and usage notes. This foundation became a design system for banking products that helps Callsign maintain consistency across new security features and future modules.

On the engineering side we aligned early with the front end team. Policy and workflow components were modelled as React units that can be composed to create more complex screens without duplication. For example, the same policy summary module appears in configuration lists, in the workflow canvas and in evaluation results, with a consistent behaviour contract. The D Three based visualisations sit inside dedicated React containers so layout and rendering responsibilities are clearly separated, which supports performance tuning for larger datasets.

We structured deliverables to fit their development process during Implementation Partnership. Specifications followed the structure of their existing work in Git and Confluence, and we joined regular sessions with engineers to resolve edge cases before they reached implementation. After around eight weeks the project reached a stable state. The new workflows and policy management interfaces were ready for enterprise demos and the design system was complete enough to guide further internal work. Callsign's own designers later used this system as the basis for additional modules beyond fraud and authentication.