Design ruling · R86 · 2 Aug 2026

Bank connect: two decisions before anyone writes code

You said the shipped screen felt like a quick mockup, not something people would pay for. This is the design that replaces it. Nothing gets built until you approve or revise these two things.

Silence is not approval. Reply with “approve both”, or say what to change.

Why this came up

When you connected your real Amex, three things went wrong on screen. None of them in the data layer. All of them in the experience.

• Two silent waits — roughly 3–5 seconds each, with nothing on screen to explain them.
• Confetti fired early, while the page still said “No bank connected.”
• Card naming varies by bank. Amex named your cards automatically. Chase and others return only “Card ·1234”, so someone has to match them by hand.

I confirmed all three in the code. I did not take the report on trust. The celebration really does fire the instant the connection is saved, before any spending has been pulled in.

What the screen looks like afterwards

Before you connect

Today this is a card that says “No bank connected.” That is a dead end, not a screen that sells anything. It becomes an explainer that tells you what is about to happen:

Beside it sits a “Know what to expect” card. It sets the card-naming expectation honestly before you commit, instead of surprising you afterwards:

American Express identifies card names automatically. Other banks may return only a generic card label and its last four digits. After sync, we’ll ask you to match labels such as “Card ·1234” to the card product in your wallet.

While it is working

One progress card stays on screen the whole time and always names the current wait. No more dead air. Progress is ordinal. Four named stages, never a fake percentage.

Confetti moves to the end. It fires only after the connection is saved, the first import has actually finished, and the success screen is visibly painted. It cannot fire over a page that still says “No bank connected.”

After it connects

You see which bank is connected, when it last synced, and which cards were recognised. The screen keeps the distinction between a card the system matched itself and one you picked:

✓ Auto-matched✓ You choseCard type required

Cards it cannot identify get a “Choose type” action instead of a guess. The system never guesses an ambiguous rewards product. Guessing wrong quietly corrupts every recommendation after it.

Anything it cannot show honestly says so:

Only cards with categorized spending in the latest synced month appear here. A selected account may appear after a later sync.

When something breaks

Every failure state gets durable, specific copy — never a toast that vanishes, never a generic “something went wrong”. Here is the one that matters most. If the app cannot tell whether a connection was created, it hides the Connect button and asks you to check status first. That stops you creating a second bank connection that bills every month.

The flow, end to end

If you close Plaid partway, the app checks whether a connection was actually created before it tells you anything. It never says “cancelled” when a billable connection quietly exists.

What I checked before putting this in front of you

I tested the spec against the actual code. Everything it claims held up:

• The six privacy and consent sentences it quotes match the shipped source word for word. The design reuses your one approved wording instead of writing a second copy that can drift.
• The celebration really does fire before spending is imported.
• The current page really does sit outside the design system. That is why none of the 70 existing components applied to it.
• The two new components it asks for genuinely do not exist yet.
• The card-matching behaviour it reuses is real and stays intact.

What this does not change

• No backend change. The server side stays exactly as deployed.
• Your four earlier rulings stand: the dedicated signed-in page, the “cards detected in your latest synced month” wording, one global disconnect, and reset-and-start-over in place of a “Reconnect” button that would quietly create a second billing connection.
• Nothing was built, merged, deployed, or turned on to produce this page.

If you approve

1. The flow gets built once and rendered in both places.
2. The invented styles get deleted, not restyled.
3. It goes back for an independent check against the real bytes. That includes screenshots at phone, tablet and desktop sizes in both light and dark mode, before it counts as done.

Prepared by the autonomous relay poller on 2 August 2026, while you were away. This page is a readable summary for review on a phone. The full 453-line spec, including the build contract and its 21 acceptance gates, is in the relay repo at exchange/from-auditor/DESIGN-SPEC-R86-PLAID-VISUAL-INTERACTION-2026-08-02.md. Nothing here is a commitment to a ship date.