Skip to content

feat(grid-visualizer): add SWIFT_ACCOUNT to accountTypeSpecs - #775

Closed
shreyav wants to merge 1 commit into
mainfrom
claude/visualizer-swift-account
Closed

feat(grid-visualizer): add SWIFT_ACCOUNT to accountTypeSpecs#775
shreyav wants to merge 1 commit into
mainfrom
claude/visualizer-swift-account

Conversation

@shreyav

Copy link
Copy Markdown
Contributor

Summary

SWIFT_ACCOUNT exists everywhere else in this repo — the OpenAPI schemas (SwiftAccountInfoBase.yaml, ExternalAccountType.yaml, ExternalAccountInfoOneOf.yaml, PaymentInstructions.yaml), the Mintlify docs (mintlify/snippets/external-accounts.mdx has a SWIFT tab), the grid-api skill reference (.claude/skills/grid-api/references/account-types.md), and the generated bankAccountFields.generated.ts in both components/grid-wallet-demo and components/grid-wallet-prod.

It was missing from exactly one place: components/grid-visualizer/src/data/account-types.ts. This PR adds it.

This supersedes the SWIFT portion of #478 and #531, both of which are being closed as largely superseded — the rest of their content already landed on main via later syncs. This one entry is the genuine remainder.

Fields

Derived from openapi/components/schemas/common/SwiftAccountInfoBase.yaml rather than from the old PR descriptions:

FieldSchema status
countryrequired (ISO 3166-1 alpha-2)
swiftCoderequired
bankNamerequired
accountNumberoptional — "Required for most corridors"
ibanoptional — "Required for IBAN-only corridors (e.g. BR, GB)"

accountNumber and iban are conditionally exclusive. Both are listed with disambiguating descriptions, matching how the file already handles the same situation for PKR_ACCOUNT, EGP_ACCOUNT, SLV_ACCOUNT and COP_ACCOUNT.

beneficiaryRequired: true — every fiat bank account type in the file sets this, and the SWIFT example in mintlify/snippets/external-accounts.mdx includes a beneficiary block.

Example values match the Nigerian GTBank example already in the Mintlify SWIFT tab (NG / GTBINGLA / Guaranty Trust Bank / 1234567890) rather than inventing new ones. The iban example is the schema's own example.

⚠️ This entry is currently unreachable in the UI — follow-up required

I investigated how accountTypeSpecs is consumed. It is read in exactly one file, components/grid-visualizer/src/lib/code-generator.ts, always as a lookup keyed by CurrencySelection.accountType:

  • buildAccountInfoBody()accountTypeSpecs[sel.accountType]
  • generateSteps()accountTypeSpecs[destination.accountType] / accountTypeSpecs[source.accountType]

Every CurrencySelection is constructed from one of only two data sources:

  • data/currencies.tsFiatCurrency.accountType, a single string per currency (built in CurrencyPicker.lookupSelection() and hooks/useFlowBuilder.ts)
  • data/crypto.tsCryptoAsset.accountTypes[].type

SWIFT_ACCOUNT is not a currency; it's a cross-currency correspondent-banking account type, so it appears in neither. Nothing in the visualizer can currently produce accountType === 'SWIFT_ACCOUNT', so this spec is dead data until a follow-up lands.

I am deliberately not fixing that here: two other PRs are in flight against components/grid-visualizer/src/data/currencies.ts and touching it would create conflicts. The account-types.ts entry is correct and needed either way, so it ships now.

What the follow-up needs to do: allow a fiat currency to offer more than one account type, and let the user choose. Concretely:

  1. In data/currencies.ts, widen FiatCurrency beyond the single accountType: string — e.g. add an optional alternateAccountTypes?: { type: string; label: string }[] — and add SWIFT_ACCOUNT as an alternate on the currencies where an international wire is a real option.
  2. In components/InputCard/InputCard.tsx, add a fiat equivalent of the existing getNetworkOptions() / NetworkDropdown pattern (which already does exactly this for crypto assets with more than one accountTypes entry), so the selected account type flows into CurrencySelection.accountType.
  3. Thread the choice through CurrencyPicker.lookupSelection() and hooks/useFlowBuilder.ts, both of which currently hard-assign accountType: fiat.accountType.

Once that lands, the spec added here is picked up by code-generator.ts with no further change.

Testing / what I could not verify

  • ✅ Typechecked the changed file standalone: npx tsc --noEmit --strict --ignoreConfig --ignoreDeprecations 6.0 --target es2020 --moduleResolution bundler --module esnext src/data/account-types.ts — clean. The file is pure TypeScript with no imports, so this is a complete check of it.
  • No full build or dev-server run.npm ci in components/grid-visualizer fails because @central-icons-react requires a CENTRAL_LICENSE_KEY env var that is not available in this environment. I have not run the app, the project-wide tsc, ESLint, or any visual check.
  • ❌ Consequently the rendered output was not verified — though as described above, there is currently no UI path that would render it.

There are no tests covering account-types.ts in this component.


Generated by Claude Code

SWIFT_ACCOUNT is defined in the OpenAPI schemas, the Mintlify external
account docs, the grid-api skill reference and the generated bank account
fields for both wallet demos, but was missing from the visualizer's
account type specs.
Fields and required/optional split are derived from
openapi/components/schemas/common/SwiftAccountInfoBase.yaml; example values
match the Nigerian GTBank example in mintlify/snippets/external-accounts.mdx.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MMnjJ8yWJsui7jLqqrDrL4
@vercel

vercelBot commented Jul 30, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

ProjectDeploymentActionsUpdated (UTC)
grid-flow-builderReadyReadyPreviewJul 30, 2026 8:20pm
1 Skipped Deployment
ProjectDeploymentActionsUpdated (UTC)
grid-wallet-demoIgnoredIgnoredJul 30, 2026 8:20pm

Request Review

@greptile-apps

Copy link
Copy Markdown
Contributor

Greptile Summary

Adds the missing SWIFT account metadata to the Grid visualizer.

  • Defines the required country, SWIFT code, and bank name fields.
  • Includes the corridor-dependent account number and IBAN examples.
  • Marks beneficiary information as required, consistently with other fiat bank account types.

Confidence Score: 5/5

The PR appears safe to merge, with no actionable defect in the added static account-type metadata.

The new entry matches the repository’s SWIFT field definitions, and its currently unreachable state prevents it from altering generated visualizer output.

Important Files Changed

FilenameOverview
components/grid-visualizer/src/data/account-types.tsAdds a schema-aligned SWIFT_ACCOUNT specification; it remains unreachable until the visualizer supports selecting alternate fiat account types.

Reviews (1): Last reviewed commit: "feat(grid-visualizer): add SWIFT_ACCOUNT..." | Re-trigger Greptile

@shreyavshreyav closed this Jul 30, 2026
shreyav added a commit that referenced this pull request Aug 4, 2026
## Summary
`currencies.ts` had drifted behind `account-types.ts`. Eleven account
types had specs but no currency entry — **AED, BDT, BWP, COP, EGP, GHS,
GTQ, HTG, JMD, PKR, XAF**.
That's not cosmetic. The picker iterates `currencies`, and
`CurrencySelection.accountType` is only ever set from
`FiatCurrency.accountType` or `CryptoAsset.accountTypes[].type`. A
currency absent from this file cannot be selected, so its corridor
cannot be built, previewed, or code-generated at all. Takes the list
from 26 entries to 37.
This became more consequential after #776: rails are now sent to the API
as `destination.paymentRail`, so entries have to carry real
`PaymentRail` enum values, not display strings.
## Where the rails came from
Each currency's rails are taken from its `paymentRails` enum in
`openapi/components/schemas/common/<Ccy>AccountInfo.yaml` — the
authoritative list of what that account type supports. **Not** inferred
from the account-type field shapes, which only hint at it.
| Currency | Rails |
|---|---|
| AED, GTQ, JMD | `BANK_TRANSFER` |
| BWP, HTG, XAF | `MOBILE_MONEY` |
| BDT, COP, EGP, GHS, PKR | `BANK_TRANSFER`, `MOBILE_MONEY` |
**None of the eleven has an instant rail**, so all carry `instantRails:
[]`. That has a behavioral consequence worth confirming: `jitEligible`
is computed as `instantRails.length > 0`, so none of these currencies
will offer just-in-time funding. That matches the schemas, but it's the
kind of thing worth a second opinion from someone who knows the
corridors.
## Flags
Eight of the eleven had no flag asset, and `getIconSrc` returns
`/flags/<code>.svg` unconditionally — they would have rendered broken.
Added `ae`, `bd`, `co`, `eg`, `gt`, `ht`, `jm`, `pk`.
Sourced from `circle-flags`, which is already a dependency and is where
the existing 39 came from — I verified an existing flag is
byte-identical to the package's copy before using it, so these match the
current set exactly rather than merely resembling it.
**Also adds `sv.svg`, which fixes a pre-existing bug.** The El Salvador
entry has referenced a flag that was never committed, so it renders
broken on `main` today. Unrelated to the eleven, but it's a one-file fix
in exactly the area this PR touches. Happy to split it out if you'd
rather keep the diff clean.
## `REGION_SHORT`
Added the eight new two-letter codes in `InputCard.tsx`. Its lookup is
`REGION_SHORT[region] ?? region`, so a missing entry already degrades to
the raw currency code — this is display polish, not a fix.
`getCountryName` in `flow-path.ts` needed nothing: its
`countryCode.toUpperCase()` fallback already produces exactly the
`GT`-style output its map contains.
## Verification
Checked mechanically across the whole file, not just the new rows:
- Strict typecheck of `currencies.ts` — clean
- All 11 `accountType` values exist in `account-types.ts`
- Every rail in the file is a valid `PaymentRail` member
- Every `countryCode` in the file now resolves to a flag that exists
**Not verified:** no build or render check. `npm ci` fails here because
`@central-icons-react` requires `CENTRAL_LICENSE_KEY`. The Vercel
preview is the real check — worth eyeballing the picker for the 11 new
rows and their flags.
## Judgment calls to second-guess
- **`accountLabel` for dual-rail currencies.** Used `"<Country> Bank
Account"`, following `CNY_ACCOUNT`. The other dual-rail precedent,
`SLV_ACCOUNT`, uses `"El Salvador Bank/Mobile"`. Mixed precedent in the
file; I picked the more common form.
- **`AED` uses `accountLabel: 'IBAN'`**, matching EUR and DKK, because
its account type is IBAN-based rather than account-number-based.
- **`XAF` uses `countryCode: 'cm'`** (Cameroon) for a multi-country CFA
zone, mirroring how `XOF` uses `'sn'`.
- **Example people** are invented, following the file's existing
convention of one plausible local name per currency.
## Related
Fills the `currencies.ts` half of the drift found while triaging the
stale docs-sync PRs. The remaining known gap in this area is surfacing
`SWIFT_ACCOUNT`, which needs `FiatCurrency` widened beyond a single
`accountType` plus a fiat account-type dropdown — see closed#775 for
the schema research.
---
_Generated by [Claude
Code](https://claude.ai/code/session_01MMnjJ8yWJsui7jLqqrDrL4)_
Co-authored-by: Claude <noreply@anthropic.com>
shreyav added a commit that referenced this pull request Aug 4, 2026
## Summary
`external-accounts.mdx` documented **21 of the 45** account types in
`ExternalAccountType`. Because the page reads as an enumeration — a tab
per country or rail — a developer scanning it would reasonably conclude
the other 24 aren't supported. This documents all of them.
Docs-only, one file, +927 lines. Generated bundles untouched.
**Coverage is now 45/45**, verified by diffing the `accountType` values
in the page against `account-types.ts`.
| Added | Types |
|---|---|
| 18 fiat tabs | `AED` `BDT` `BWP` `CNY` `DKK` `EGP` `GHS` `GTQ` `HKD`
`HTG` `IDR` `JMD` `MYR` `PKR` `SGD` `THB` `VND` `XAF` |
| Cryptocurrency tab | Ethereum L1, Base, Polygon, Solana, Tron, Plasma,
Lightning — it previously showed Spark alone |
## Scope grew during the work — worth knowing
I started from a list of 17 missing types. A mechanical diff against
`account-types.ts` found **24**: `DKK`, `HKD`, `IDR`, `MYR`, `SGD`,
`THB`, `VND` and `LIGHTNING` weren't on my list. Stopping at 17 would
have reproduced the same partial-coverage problem in a PR whose entire
purpose is fixing it, so all 24 are here.
## Where the content comes from
Nothing is inferred from existing examples — each type was read from its
schema:
- **Fields and required/optional split** — `<Ccy>AccountInfoBase.yaml`
- **Beneficiary shape** — `<Ccy>Beneficiary.yaml`, which is where the
real variation lives. Most need only `fullName`, but **AED** and **JMD**
also require an `address`, **GTQ** requires `countryOfResidence` and
`phoneNumber`, and **JMD** requires `phoneNumber`. Those are easy to
miss and produce confusing validation failures.
- **Per-chain asset support** — each `Payment<Chain>WalletInfo.yaml`.
Ethereum carries `USDC` and `USDT`; Base and Polygon are USDC-only.
Stated per chain rather than assumed uniform.
- **Dual-rail currencies** (BDT, CNY, EGP, GHS, PKR) get separate
bank-transfer and mobile-money examples, following the existing Colombia
and El Salvador tabs.
**No example sends `paymentRails`.** It's response-only, and three
separate PRs (#351, #661, and the original #359 lineage) got that wrong.
The single occurrence of it in this file remains where it belongs — the
`GET` **response** example.
Example people match the entries added to `currencies.ts` in #791, so
the docs and the visualizer describe the same fictional customers.
## Verification
- **All 54 curl payloads in the file parse as JSON** — not just the new
ones
- **Every `accountType` used is a valid `ExternalAccountType` member**
- **Coverage diff is empty**: no type in `account-types.ts` is
undocumented
- MDX component tags and code fences balance
- All new curl examples use `-u`, consistent with #793
- `openapi.yaml` and `mintlify/openapi.yaml` byte-identical to `main`
**Not verified:** no visual render. This is 927 lines of new tabs, so
the **Mintlify preview is the meaningful review** — worth checking that
the tab strip doesn't overflow badly now that it holds 32 tabs. `make
lint` was not run; it fails on `main` regardless (`npx spectral lint`
resolves to a stub `spectral@0.0.0`).
## One thing this surfaces
`SWIFT_ACCOUNT` is documented here but **absent from
`account-types.ts`**, so the visualizer still can't produce it. That's
the known gap from closed#775 — the entry was correct but unreachable
without widening `FiatCurrency` past a single `accountType`. Unchanged
by this PR, but the asymmetry is now visible: the docs describe a type
the visualizer can't build.
## Left out deliberately
I had also listed adding SWIFT to `account-model.mdx`. **That item
doesn't hold up.** My earlier check used the wrong path — the file is at
`platform-overview/core-concepts/account-model.mdx`, not `snippets/`.
Looking at the real file, it's an explicitly illustrative page showing 8
representative types, not an enumeration. Singling out SWIFT there would
recreate the curated-list problem rather than fix one. Left alone.
---
_Generated by [Claude
Code](https://claude.ai/code/session_01MMnjJ8yWJsui7jLqqrDrL4)_
---------
Co-authored-by: Claude <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@shreyav@claude