* Product details and visuals have been generalized to respect organizational confidentiality.
TL;DR
I designed a rule-based data workflow that protects integrity in complex financial systems by treating rare, high-impact edge cases as first-class—not afterthoughts.
Overview
An internal platform for creating and maintaining structured financial instrument records that feed downstream rating and research systems. Errors here compound across the ecosystem. As the solo designer, I owned record creation flows, interaction logic, UI specs, and cross-functional alignment.
Problem Space
Complexity here doesn't come from happy-path forms. It comes from the long tail: fields are tightly interdependent, validation stacks in layers, and lifecycle actions change what downstream systems are allowed to assume.
Standard assumptions cover most volume—but edge cases are where failures are most likely and most costly, because stewards and systems are least prepared for them.
Governing Input Correctness
Once pricing and risk consume a value, correcting it is slow and visible. This section is only about validation: how rules are timed, where they fire, and how the same logic stays consistent across instrument sections—so stewards fix problems while the cost is still local.
I structured validation in four layers that map to when risk should be caught:
Prevent removes avoidable input up front (for example, system-derived defaults).
Guide gives inline direction while editing (required states, date continuity, allowed ranges).
Enforce blocks invalid commits at save/submit boundaries.
Reuse applies the same rule pattern across related schedules so logic stays consistent instead of being rewritten per field group.
Currency change — worked example
Real validation rules from the currency-change schedule, tagged by stack:
| Stack | Field | Rule | When |
|---|---|---|---|
| Prevent | Face Amt | Auto-populates when Eff. Date ≤ today | Immediate |
| Guide | Currency | Required when Face Amount is filled | Immediate |
| Guide | Eff. Date | Must match previous row’s Term. Date | Immediate |
| Guide | Eff. / Term. | Picker limited to 50yr past – 100yr future | On pick |
| Enforce | Term. Date | Must be after Eff. Date (≥ 1 day) | Immediate |
| Enforce | Term. Date | Required except on last row | Submit |
| Reuse | Coupon, Dividend, … | Same row + date-span validators as above attach to other sections—Coupon and Dividend (and similar schedules) bind different field names to one shared pattern. | — |
Record Management & System Communication
Lifecycle · Staging · Integration · Edge cases
Lifecycle states
Routine field edits are fundamentally different from lifecycle transitions — events that change a record's availability across the entire ecosystem. "Inactive" alone isn't sufficient: withdrawal after a credit event, deal cancellation, temporary hold, and maturity each carry different reactivation rules and downstream consequences. Each transition requires explicit confirmation with cross-system impact surfaced before execution.
Staging
Edits go through a staging layer before they reach the canonical record. Each staged revision is bound to a single rating transaction — the record stays Active throughout, and multiple analysts can stage changes to the same instrument without colliding.
Integration surface
The instrument search surface is built to work inside other systems. Connected platforms embed it as an iframe, passing entity context and pre-filled search criteria. The same layout handles it: search absorbs pre-filled filters, the table supports multi-select, and action buttons reflect the current selection — no separate "embedded mode," no parallel codebase.
Edge-case disclosure
A small fraction of cases drive disproportionate risk. The UI uses progressive disclosure so everyday work stays quiet while edge cases stay reachable: certain fields surface a dedicated dynamic section only when an external source triggers an update requiring additional input — hidden during routine editing, present when the data context demands it.
Reflection
Rule-based systems excel at correctness until the task requires external data retrieval or deciding whether an entity already exists. That gap is where AI-assisted patterns belong: inside the workflow, not as a replacement for it — the line of thinking that fed directly into the AI and semantic-search work in the next case.