Wir begannen damit, die Mechanik der Richtlinien-Engine durch Domain Learning explizit zu machen. Richtlinien kombinieren in diesem Kontext Bedingungen zu Verhaltensindikatoren wie Device-Fingerprint, Standortänderung, Ausgabengeschwindigkeit und vorheriger Fehlerhistorie mit Ergebnissen wie Zulassen, Blockieren oder Auslösen erhöhter Authentifizierung. Das bestehende Interface legte diese Regeln als Datenbankansichten und Konfigurationstabellen offen. Es entsprach nicht der Art, wie Analysten über Betrugsmuster denken oder wie sie Entscheidungen gegenüber internen Auditteams erklären.

Durch Workshops mit Callsign-Produkt-, Engineering- und Sicherheitsspezialisten während der Sandbox Experiments kartierten wir die bestehenden Regelstrukturen, die Betrugsszenarien, die sie abdecken mussten, und die Punkte, an denen Konflikte oder Lücken auftraten. Diese Kartierungsübung führte zu einer klaren Trennung zwischen dem Betrugserkennungsmodell, das Ereignisse bewertet, und der Richtlinienebene, die Schwellenwerte, Überschreibungen und Workflow-Entscheidungen anwendet. Die Arbeit wurde zu einem Stück UX-Design für KI-Systeme, bei dem das Interface steuert, wie Modellausgaben in reale Aktionen fließen.

Von dort aus definierten wir eine Informationsarchitektur für Enterprise-Sicherheit, die eine Richtlinie als zentrales Objekt behandelte. Jede Richtlinie bündelt ihre Bedingungen, Aktionen, Historie und Links zu verwandten Regeln. Analysten können eine Richtlinie von der Definition bis zur Evaluierung verfolgen, ohne den Kontext zu verlassen. Entscheidungen werden auf eine Weise aufgezeichnet, die Audit-Überprüfung und regulatorische Kontrollen im Zusammenhang mit SCA, PCI DSS und interner Governance unterstützt. Wir validierten frühe Versionen dieser Struktur mit Callsign-Teams unter Verwendung prägnanter Szenarien statt abstrakter Diagramme und passten basierend auf ihrem Feedback an.

Mit der Architektur an Ort und Stelle gestalteten wir Analysten-Journeys neu, um widerzuspiegeln, wie Betrugs-Teams tatsächlich einen Fall durchdenken. Die vorherige Erfahrung zwang Benutzer, zwischen Konfigurationsbildschirmen, Referenzdokumenten und Datentabellen zu springen, wenn sie eine einzelne Regel anpassen wollten. Wir ersetzten dies durch einen richtlinienzentrierten Flow. Analysten identifizieren ein Szenario, öffnen das relevante Richtlinienset, passen Bedingungen im Kontext an und sehen sofort, wo im Workflow die Änderung gilt.

Das Kerninteraktionskonzept war ein Drei-Gesten-Modell, das für Interaktionsdesign für Betruganalisten entwickelt wurde. Analysten ziehen, um Knoten im Workflow zu erstellen oder neu zu positionieren, klicken, um Regelparameter inline zu öffnen und zu bearbeiten, und zeichnen eine Verbindung, um Knoten zu verknüpfen und die Sequenzierung zu definieren. Diese Gesten sind im gesamten Tool konsistent, was den Lernaufwand für Benutzer niedrig hält, die aus Risiko- oder Compliance-Hintergründen kommen statt aus Produkthintergründen.

Wir mussten auch Scope-Abwägungen durch tension-driven reasoning treffen. Für die erste Veröffentlichung priorisierten wir Richtlinienerstellung, Konfliktsichtbarkeit und Wirkungserklärung über erweiterte Kollaborationsfunktionen oder vollständige Versionsgeschichtsansichten. Diese Entscheidung spiegelte das unmittelbare Ziel wider, Demos mit Risiko- und Sicherheitsteams bei großen Banken effektiv und glaubwürdig zu machen. Frühe interne Tests mit Callsign-Analysten bestätigten, dass die neuen Journeys die Zeit reduzierten, die benötigt wurde, um ein gängiges Betrugsszenario im Tool auszudrücken, und Erklärungen während Kundengesprächen unkomplizierter machten.

Konfiguration allein war nicht ausreichend. Callsign benötigte eine Möglichkeit für Analysten und Bank-Stakeholder zu verstehen, was ein gegebenes Set von Richtlinien in realistischen Szenarien tun würde. Wir schufen einen Evaluierungsmodus, in dem Benutzer einen Simulationskontext mithilfe von Filtern im Stil natürlicher Sprache definieren, wie Kundensegment, Geografie oder Transaktionstyp. Das System führt diese Einstellungen dann durch das Betrugserkennungsmodell und die Richtlinien-Engine und präsentiert die Ergebnisse in einer fokussierten analytischen Ansicht.

Die Evaluierungsansicht ist zentral für die Benutzererfahrung von Risikomanagement-Tools, weil sie die Schleife zwischen Konfiguration und Auswirkung schließt. Analysten können sehen, wie oft ein Szenario zu automatischer Genehmigung, erhöhter Authentifizierung oder Blockierung führen würde, und können prüfen, ob Hochrisikofälle durchrutschen würden. Um dies interpretierbar zu machen, verließen wir uns auf Datenvisualisierung für Banksysteme, implementiert mit D3, wobei wir Graphen- und Flow-Darstellungen verwendeten, die hervorheben, wo sich Verkehr konzentriert und wo Richtlinien Engpässe erzeugen.

Wir hielten die Beziehung zwischen Konfiguration und Evaluierung sehr klar. Richtlinien werden immer im Konfigurationsbereich bearbeitet, und die Evaluierungsumgebung konsumiert diese Definitionen, ohne Benutzern zu erlauben, sie vor Ort zu ändern. Diese Schutzschiene vermeidet unverfolgte Änderungen während der Analyse. Wir verwendeten evidenzbasierte UX für KI, um den Evaluierungsflow zu verfeinern, beobachteten, wie Analysten die Diagramme interpretierten und wo Fehlinterpretationen auftraten, und vereinfachten dann entsprechend Labels und Interaktionen. Das Ergebnis ist eine kontrollierte, aber flexible Schleife, in der Analysten Richtlinienstrategien testen, anpassen und rechtfertigen können, ohne Modell-Interna offenzulegen.

Von den ersten Wochen an behandelten wir jeden Bildschirm als Teil eines Design Systems statt als einmaliges Artefakt während der Concept Convergence. Das System umfasst Workflow-Konstruktion, Richtlinienmanagement, Evaluierungsansichten und unterstützende Navigationsstrukturen. Jede Komponente hat dokumentierte Zustände, Interaktionsregeln und Verwendungshinweise. Dieses Fundament wurde zu einem Design System für Bankprodukte, das Callsign hilft, Konsistenz über neue Sicherheitsfunktionen und zukünftige Module hinweg aufrechtzuerhalten.

Auf der Engineering-Seite stimmten wir uns früh mit dem Front-End-Team ab. Richtlinien- und Workflow-Komponenten wurden als React-Einheiten modelliert, die zusammengesetzt werden können, um komplexere Bildschirme ohne Duplikation zu erstellen. Zum Beispiel erscheint dasselbe Richtlinienzusammenfassungsmodul in Konfigurationslisten, im Workflow-Canvas und in Evaluierungsergebnissen, mit einem konsistenten Verhaltensvertrag. Die D3-basierten Visualisierungen befinden sich in dedizierten React-Containern, sodass Layout- und Rendering-Verantwortlichkeiten klar getrennt sind, was Performance-Tuning für größere Datensätze unterstützt.

Wir strukturierten Deliverables passend zu ihrem Entwicklungsprozess während der Implementation Partnership. Spezifikationen folgten der Struktur ihrer bestehenden Arbeit in Git und Confluence, und wir nahmen an regelmäßigen Sitzungen mit Ingenieuren teil, um Edge Cases zu lösen, bevor sie die Implementierung erreichten. Nach etwa acht Wochen erreichte das Projekt einen stabilen Zustand. Die neuen Workflows und Richtlinienmanagement-Interfaces waren bereit für Enterprise-Demos und das Design System war vollständig genug, um weitere interne Arbeit zu leiten. Callsigns eigene Designer verwendeten dieses System später als Basis für zusätzliche Module jenseits von Betrug und Authentifizierung.