Uh oh!
There was an error while loading. Please reload this page.
feat(grid-visualizer): add SWIFT_ACCOUNT to accountTypeSpecs - #775
Closed
shreyav wants to merge 1 commit into
Closed
feat(grid-visualizer): add SWIFT_ACCOUNT to accountTypeSpecs#775shreyav wants to merge 1 commit into
shreyav wants to merge 1 commit into
Conversation
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
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
Contributor
Greptile SummaryAdds the missing SWIFT account metadata to the Grid visualizer.
Confidence Score: 5/5The 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.
|
| Filename | Overview |
|---|---|
| components/grid-visualizer/src/data/account-types.ts | Adds 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
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
SWIFT_ACCOUNTexists everywhere else in this repo — the OpenAPI schemas (SwiftAccountInfoBase.yaml,ExternalAccountType.yaml,ExternalAccountInfoOneOf.yaml,PaymentInstructions.yaml), the Mintlify docs (mintlify/snippets/external-accounts.mdxhas a SWIFT tab), the grid-api skill reference (.claude/skills/grid-api/references/account-types.md), and the generatedbankAccountFields.generated.tsin bothcomponents/grid-wallet-demoandcomponents/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
mainvia later syncs. This one entry is the genuine remainder.Fields
Derived from
openapi/components/schemas/common/SwiftAccountInfoBase.yamlrather than from the old PR descriptions:countryswiftCodebankNameaccountNumberibanaccountNumberandibanare conditionally exclusive. Both are listed with disambiguatingdescriptions, matching how the file already handles the same situation forPKR_ACCOUNT,EGP_ACCOUNT,SLV_ACCOUNTandCOP_ACCOUNT.beneficiaryRequired: true— every fiat bank account type in the file sets this, and the SWIFT example inmintlify/snippets/external-accounts.mdxincludes abeneficiaryblock.Example values match the Nigerian GTBank example already in the Mintlify SWIFT tab (
NG/GTBINGLA/Guaranty Trust Bank/1234567890) rather than inventing new ones. Theibanexample is the schema's own example.I investigated how
accountTypeSpecsis consumed. It is read in exactly one file,components/grid-visualizer/src/lib/code-generator.ts, always as a lookup keyed byCurrencySelection.accountType:buildAccountInfoBody()→accountTypeSpecs[sel.accountType]generateSteps()→accountTypeSpecs[destination.accountType]/accountTypeSpecs[source.accountType]Every
CurrencySelectionis constructed from one of only two data sources:data/currencies.ts—FiatCurrency.accountType, a single string per currency (built inCurrencyPicker.lookupSelection()andhooks/useFlowBuilder.ts)data/crypto.ts—CryptoAsset.accountTypes[].typeSWIFT_ACCOUNTis not a currency; it's a cross-currency correspondent-banking account type, so it appears in neither. Nothing in the visualizer can currently produceaccountType === '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.tsand touching it would create conflicts. Theaccount-types.tsentry 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:
data/currencies.ts, widenFiatCurrencybeyond the singleaccountType: string— e.g. add an optionalalternateAccountTypes?: { type: string; label: string }[]— and addSWIFT_ACCOUNTas an alternate on the currencies where an international wire is a real option.components/InputCard/InputCard.tsx, add a fiat equivalent of the existinggetNetworkOptions()/NetworkDropdownpattern (which already does exactly this for crypto assets with more than oneaccountTypesentry), so the selected account type flows intoCurrencySelection.accountType.CurrencyPicker.lookupSelection()andhooks/useFlowBuilder.ts, both of which currently hard-assignaccountType: fiat.accountType.Once that lands, the spec added here is picked up by
code-generator.tswith no further change.Testing / what I could not verify
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.npm ciincomponents/grid-visualizerfails because@central-icons-reactrequires aCENTRAL_LICENSE_KEYenv var that is not available in this environment. I have not run the app, the project-widetsc, ESLint, or any visual check.There are no tests covering
account-types.tsin this component.Generated by Claude Code