Skip to content

Add USD account bank, account type and wire routing fields - #765

Closed
ls-bolt[bot] wants to merge 1 commit into
mainfrom
07-29-usd-account-wire-fields
Closed

Add USD account bank, account type and wire routing fields#765
ls-bolt[bot] wants to merge 1 commit into
mainfrom
07-29-usd-account-wire-fields

Conversation

@ls-bolt

@ls-boltls-boltBot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

This PR has been claimed. The active PR is now #778.

Summary

Adds the USD account fields needed to describe a domestic wire beneficiary, and purposeOfPayment on TransferOutRequest.

UsdAccountInfoBase carried only accountNumber and routingNumber, so a USD account could not express which bank holds it, whether it is checking or savings, or how to reach it through a correspondent. Every other bank-account shape in the spec already has at least bankNameSwiftAccountInfoBase requires it, and SlvAccountInfoBase has both bankName and bankAccountType with the same CHECKING/SAVINGS enum reused here.

Two of these fields were already documented but never existed in the spec: the "United States" example in snippets/external-accounts.mdx shows bankAccountType and bankName on a USD_ACCOUNT, and the note below it says "Category must be CHECKING or SAVINGS". This change makes those docs true.

Changes

openapi/components/schemas/common/UsdAccountInfoBase.yaml — five optional properties, no change to required:

PropertyTypeNotes
bankNamestring, 1–140Institution holding the account
bankAccountTypeCHECKING | SAVINGSSame enum as SlvAccountInfoBase
intermediaryBankNamestring, 1–140WIRE rail only
intermediaryRoutingNumberstring, 9 digits, ^[0-9]{9}$WIRE rail only
fiToFiInformationstring, ≤210Bank-to-bank instructions, WIRE rail only

Lengths follow the wire-message field sizes: 140 for party name lines, and 210 for the bank-to-bank field (six 35-character lines). intermediaryRoutingNumber mirrors the existing routingNumber constraints exactly.

openapi/components/schemas/transfers/TransferOutRequest.yaml — adds purposeOfPayment, $ref-ing the existing quotes/PurposeOfPayment.yaml. QuoteRequest already accepts it; transfer-out was the only send shape that could not record a payment purpose, even though it accepts the neighbouring remittanceInformation.

Also rebundled openapi.yaml / mintlify/openapi.yaml via make build, and documented the three wire-only fields plus purposeOfPayment in the two affected MDX pages.

Compatibility

Additive and non-breaking — every new property is optional and nothing existing changed, so info.version is unchanged.

Verified against the same gate CI runs:

$ oasdiff breaking base/openapi.yaml head/openapi.yaml --format singleline --fail-on ERR
No breaking changes to report, but the specs are different
$ echo $?
0

make lint exits 0 ("Woohoo! Your API description is valid. 🎉"). The remaining schema-properties-have-examples / -descriptions findings are pre-existing repo-wide noise; none of them are on the schemas touched here — every property added carries both a description and an example.

Test plan

  • make build — bundle regenerated, diff is additive only
  • make lint — exit 0, no findings on UsdAccountInfoBase or TransferOutRequest
  • oasdiff breaking --fail-on ERR — 0 breaking changes

@vercel

vercelBot commented Jul 29, 2026

Copy link
Copy Markdown

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

2 Skipped Deployments
ProjectDeploymentActionsUpdated (UTC)
grid-flow-builderIgnoredIgnoredPreviewJul 29, 2026 5:31pm
grid-wallet-demoIgnoredIgnoredPreviewJul 29, 2026 5:31pm

Request Review

@ls-boltls-boltBot added the bolt label Jul 29, 2026
@akanterGraphite App

Copy link
Copy Markdown
Contributor

This stack of pull requests is managed by Graphite. Learn more about stacking.

@github-actions

github-actionsBot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

✱ Stainless preview builds for grid

This PR will update the grid SDKs with the following commit messages.

cli

feat(api): add purpose_of_payment parameter to agentme/transferout create methods

go

feat(api): add purpose_of_payment to transfer out, bank details to USD external accounts

kotlin

feat(api): add fields to UsdExternalAccountCreateInfo/UsdAccountInfo/TransferOutRequest

openapi

feat(api): add bank fields to UsdAccountInfo, purposeOfPayment to TransferOutRequest

php

feat(api): add purposeOfPayment to transfer out, bank fields to USD account info

python

feat(api): add purpose_of_payment to transfers, bank fields to usd_external_account

ruby

feat(api): add bank fields to USD account models, purpose_of_payment to transfer_out

typescript

feat(api): add purposeOfPayment param to transfer-out, new fields to USD accounts

Edit this comment to update them. They will appear in their respective SDK's changelogs.

⚠️grid-typescriptstudio · code · diff

Your SDK build had a failure in the lint CI job, which is a regression from the base state.
generate ✅build ✅ (prev: build ⏭️) → lint ❗ (prev: lint ⏭️) → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/880ea6ea874ce71652bb735d98fd879c1bd2a6fc/dist.tar.gz
grid-clistudio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️build ❗lint ❗test ❗

grid-rubystudio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ✅ (prev: build ⏭️) → lint ✅test ✅

grid-openapistudio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️

grid-gostudio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅build ✅ (prev: build ⏭️) → lint ❗test ❗

go get github.com/stainless-sdks/grid-go@41e22f817b807d0b910b81f1be784b9efda5d379
grid-kotlinstudio · code · diff

Your SDK build had at least one "warning" diagnostic, but this did not represent a regression.
generate ⚠️build ✅ (prev: build ⏭️) → lint ✅ (prev: lint ⏭️) → test ❗

⚠️grid-pythonstudio · code · diff

Your SDK build had a failure in the lint CI job, which is a regression from the base state.
generate ✅build ✅ (prev: build ⏭️) → lint ❗ (prev: lint ⏭️) → test ❗

pip install https://pkg.stainless.com/s/grid-python/767d48d5e844f50c927a89e630afed7160919679/grid-0.0.1-py3-none-any.whl
grid-phpstudio · code · diff

Your SDK build had at least one "note" diagnostic, but this did not represent a regression.
generate ✅lint ✅test ✅


This comment is auto-generated by GitHub Actions and is automatically kept up to date as you push.
If you push custom code to the preview branch, re-run this workflow to update the comment.
Last updated: 2026-07-29 17:37:05 UTC

@mintlify

mintlifyBot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

Preview deployment for your docs. Learn more about Mintlify Previews.

ProjectStatusPreviewUpdated (UTC)
Grid🟢 ReadyView PreviewJul 29, 2026, 5:33 PM

peterrojs added a commit that referenced this pull request Jul 31, 2026
## Summary
Adds the USD account fields needed to describe a domestic wire beneficiary, and `purposeOfPayment` on `TransferOutRequest`.
`UsdAccountInfoBase` carried only `accountNumber` and `routingNumber`, so a USD account could not express which bank holds it, whether it is checking or savings, or how to reach it through a correspondent. Every other bank-account shape in the spec already has at least `bankName` — `SwiftAccountInfoBase` requires it, and `SlvAccountInfoBase` has both `bankName` and `bankAccountType` with the same `CHECKING`/`SAVINGS` enum reused here.
Two of these fields were **already documented** but never existed in the spec: the "United States" example in `snippets/external-accounts.mdx` shows `bankAccountType` and `bankName` on a `USD_ACCOUNT`, and the note below it says "Category must be `CHECKING` or `SAVINGS`". This change makes those docs true.
## Changes
`openapi/components/schemas/common/UsdAccountInfoBase.yaml` — five optional properties, no change to `required`:
| Property | Type | Notes |
|---|---|---|
| `bankName` | string, 1–140 | Institution holding the account; optional on every rail, recommended for wires |
| `bankAccountType` | `CHECKING` \| `SAVINGS` | Same enum as `SlvAccountInfoBase`; optional on every rail, defaults to checking |
| `intermediaryBankName` | string, 1–140 | `WIRE` rail only |
| `intermediaryRoutingNumber` | string, 9 digits, `^[0-9]{9}$` | `WIRE` rail only |
| `fiToFiInformation` | string, ≤210 | Bank-to-bank instructions, `WIRE` rail only |
Lengths follow the wire-message field sizes: 140 for party name lines, and 210 for the bank-to-bank field (six 35-character lines). `intermediaryRoutingNumber` mirrors the existing `routingNumber` constraints exactly.
`openapi/components/schemas/transfers/TransferOutRequest.yaml` — adds `purposeOfPayment`, `$ref`-ing the existing `quotes/PurposeOfPayment.yaml`. `QuoteRequest` already accepts it; transfer-out was the only send shape that could not record a payment purpose, even though it accepts the neighbouring `remittanceInformation`.
Also rebundled `openapi.yaml` / `mintlify/openapi.yaml` via `make build`, and documented the three wire-only fields plus `purposeOfPayment` in the two affected MDX pages.
## Compatibility
Additive and non-breaking — every new property is optional and nothing existing changed, so `info.version` is unchanged.
Verified against the same gate CI runs:
```
$ oasdiff breaking base/openapi.yaml head/openapi.yaml --format singleline --fail-on ERR
No breaking changes to report, but the specs are different
$ echo $?
0
```
`make lint` exits 0 ("Woohoo! Your API description is valid. 🎉"). The remaining `schema-properties-have-examples` / `-descriptions` findings are pre-existing repo-wide noise; none of them are on the schemas touched here — every property added carries both a description and an example.
## Test plan
- [x] `make build` — bundle regenerated, diff is additive only
- [x] `make lint` — exit 0, no findings on `UsdAccountInfoBase` or `TransferOutRequest`
- [x] `oasdiff breaking --fail-on ERR` — 0 breaking changes
Original PR: #765
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@akanter@peterrojs