FinCheqIQ
FinCheqIQ prototype · 11 phases · 53 screens

A cheque, from the moment it is scanned to the moment someone can prove what happened to it

A locked token layer, a component library every screen composes from, and a persistent shell carrying the whole information architecture — then forty-nine screens built on top of it across eleven phases, from the authentication suite through intake, validation, signature comparison, risk approval, core banking integration, administration and monitoring. Every phase is built and every sidebar destination resolves; nothing is left marked for later.

Phase 1 — foundation

Phase 2 — global system states

Phase 3 — operations dashboard

Phase 4 — cheque intake & processing

Phase 5 — core banking, at runtime

Phase 6 — validation results & signature comparison

Phase 7 — review workbench & risk approval

Phase 8 — queues & core banking integration

Phase 9 — notifications, audit, reports & analytics

Phase 10 — administration

Phase 11 — monitoring

Where this stands

All eleven phases are built. 53 screens, 37 live sidebar destinations with no placeholders remaining, and every internal link resolving. Eleven shared modules carry the components; not one pattern was forked into a second implementation.

Building Phase 8 last surfaced a real arithmetic fault in Phase 3: the dashboard reported “successfully exported 967”, which quietly counted cheques still in flight as settled. The correct four-way partition of the 1,043 validated cheques — 891 settled, 76 in flight, 62 held, 14 failed — now holds across the dashboard, the reports and the queue screens alike.

Every phase was verified structurally as it was built — nesting, links, icons, script targets, data reconciliation, permission gates, hash-chain continuity and language. The prototype has since been rendered and measured in a real browser, which caught a class of fault structure cannot see: a tooltip that dragged 223px of horizontal scroll across every screen, icon buttons whose glyphs rendered at 34×150px, and text as faint as 1.19:1 — including these very launcher cards, which were white on white. Contrast is now measured across all 3,051 text nodes rather than judged by eye.

Walking the flow

Sign in with any username and a password of eight characters or more to reach MFA; a shorter password returns the generic authentication error so that state is reachable without a hidden toggle.

At MFA, the first submitted code is rejected — showing the error, the shake and the attempts-remaining warning. Submit again to continue into the shell, which opens on the Operations Dashboard.

Inside the shell, all twenty-four sidebar destinations are live — there are no phase tags and no placeholders left. Collapse the sidebar to the icon rail and the choice is remembered across screens.

Narrow the window below 1024px and the sidebar becomes an off-canvas drawer; below 768px the search field folds into an icon and the topbar condenses in a fixed order.

On the Patterns screen, Go offline slides the banner in under the topbar and Reconnect runs the syncing state before clearing itself. The widget-failure panel and the timeout demo both fail once and succeed on the second attempt, so you can see the recovery as well as the failure.

The splash runs its real sequence and completes into the shell; append ?state=extended to hold it at the reassurance state, or ?state=fail to watch it hand over to the crash boundary.

On the dashboard, the viewing as control switches between Risk and Reviewer — the Reviewer loses integration health entirely and the headline pair becomes their own workload. Open Filters and choose Sur branch with Low risk to reach the empty state; any other change gives the narrowed dataset.

The integration-health panel deliberately fails on first paint so the Phase 2 widget-error pattern is visible in situ; its Retry loads the donut without touching anything else on the screen.

In Phase 4 the flow connects end to end: upload a cheque (or load the sample), submit it, follow the link into the processing queue, click any cheque ID for its details, and open extraction results from there. Dashboard rows now land on the same detail screen.

The image viewer takes zoom, drag-to-pan, rotate, front/back and keyboard + − 0 r. On Extraction Results, click a field's pencil to correct it — the row turns green-edged and stamps who changed it and when.

Open a cheque and walk the five stages. Cheque Details puts the cheque on top and the pipeline underneath as tabs, in the order it ran: extraction, internal validation, fraud detection, then two live core banking calls. Each tab badge carries that stage's own worst outcome, so the strip answers "how far did this get, and what went wrong" before you open anything. Open any check row for the evidence behind it.

Stages 4 and 5 say what they are. Both carry a banner stating that the customer, the mandate, the limits and the reference signature are read from the core banking API for that cheque and discarded. FinCheqIQ syncs nothing and stores none of it — the account number from the MICR band is the only identifier it keeps, and it is the only key used to match a cheque to an account.

The acting role is remembered as you move between screens. As Administrator every control is available; as Risk you can reveal a reference signature to compare it; as Reviewer the administration screens are replaced by a calm explanation rather than a page of disabled controls — least privilege should be invisible, not taunting.

On Validation Results, the amber strip at the top lists exactly what needs a person — click any chip and it scrolls to that group and opens the failing rows. Click any check to see the thresholds and evidence the engine used.

On Signature Comparison, reveal the registered specimen, then switch to Overlay: the two signatures tint apart — brand blue for the reference, red for the cheque — and multiply together, with a slider to fade the cheque layer in and out. Cheque 0041827 has a joint mandate, so it carries two signatories with different results each.

Walk the reviewer-checker control end to end. Start at the Reviewer Queue as N. Al-Hinai, open a cheque into the workbench, choose Reject and submit — a rationale is enforced. Then open Risk Approval on the same cheque as the same identity: the approval actions are absent and the screen explains that a different approver must complete the step. Switch the acting identity to K. Said and they appear. Approve, and the cheque is released to the Validated Cheque Queue.

The decisions persist for the session, so Reset prototype decisions at the foot of the Reviewer Queue puts the queue back if you want to walk it again.

Open the topbar bell on any screen: it now renders the same notification item the Notification Center feed uses. Mark everything read there and the bell count updates with it.

On the Audit Trail, click any row to expand its before/after diff and see the record's own hash beside the hash of the record before it. Follow this entity switches to the timeline view for that one cheque, customer or specimen.

In Administration, drag a confidence threshold and watch the three outcome bands resize with a live estimate of how many cheques would need a person. Change anything on any of the ten screens and the same sticky unsaved bar appears, leading to the same pending-approval panel used since Phase 5.

Switch the acting identity to Reviewer on any Administration screen and the whole screen is replaced by a calm explanation rather than a page of disabled controls. On Integration Configuration, hold to reveal the client secret — the same deliberate, logged interaction as a reference signature.

Phase 8 closes the loop at the far end: from the review workbench, an approved cheque lands in the Validated Cheque Queue, moves through the Integration Queue, and — because no interface is configured in this environment — waits in the Pending Integration Queue rather than being lost. Open CHQ-2026-0041688 in Transaction Details to see five failed attempts and the escalation into the Exception Queue.

The one continuous story worth walking end to end: sign in → MFA → dashboard → click cheque CHQ-2026-0041827 → its extraction, validation results and signature comparison → open it in the review workbench → submit a decision as N. Al-Hinai → try to approve it as the same person and be told why you cannot → switch to K. Said and approve it. Then open Security Monitoring and find your own signature reveal in the sensitive-access log.

Phase map

Every screen in the prototype, by the phase that built it. The cards above are the guided route; this is the complete index — 53 screens, all reachable, plus this launcher.

Phase 3 Operations dashboard Operations Dashboard 1
Phase 5 Core banking at runtime — customer, signature, limits Core banking · customerCore banking · confirmation & pass 4
Phase 6 Validation results & signature comparison Validation ResultsSignature Comparison 2
Phase 7 Review workbench & risk approval Manual Review WorkbenchReviewer QueueRisk Approval 3
Phase 9 Notifications, audit, reports & analytics Notification CenterAudit TrailReportsAnalytics 4
Phase 11 System & security monitoring System MonitoringSecurity Monitoring 2