Add USD account bank, account type and wire routing fields - #765
Add USD account bank, account type and wire routing fields#765ls-bolt[bot] wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
✱ Stainless preview builds for gridThis PR will update the cli go kotlin openapi php python ruby typescript Edit this comment to update them. They will appear in their respective SDK's changelogs.
|
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
## 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
Summary
Adds the USD account fields needed to describe a domestic wire beneficiary, and
purposeOfPaymentonTransferOutRequest.UsdAccountInfoBasecarried onlyaccountNumberandroutingNumber, 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 leastbankName—SwiftAccountInfoBaserequires it, andSlvAccountInfoBasehas bothbankNameandbankAccountTypewith the sameCHECKING/SAVINGSenum reused here.Two of these fields were already documented but never existed in the spec: the "United States" example in
snippets/external-accounts.mdxshowsbankAccountTypeandbankNameon aUSD_ACCOUNT, and the note below it says "Category must beCHECKINGorSAVINGS". This change makes those docs true.Changes
openapi/components/schemas/common/UsdAccountInfoBase.yaml— five optional properties, no change torequired:bankNamebankAccountTypeCHECKING|SAVINGSSlvAccountInfoBaseintermediaryBankNameWIRErail onlyintermediaryRoutingNumber^[0-9]{9}$WIRErail onlyfiToFiInformationWIRErail onlyLengths follow the wire-message field sizes: 140 for party name lines, and 210 for the bank-to-bank field (six 35-character lines).
intermediaryRoutingNumbermirrors the existingroutingNumberconstraints exactly.openapi/components/schemas/transfers/TransferOutRequest.yaml— addspurposeOfPayment,$ref-ing the existingquotes/PurposeOfPayment.yaml.QuoteRequestalready accepts it; transfer-out was the only send shape that could not record a payment purpose, even though it accepts the neighbouringremittanceInformation.Also rebundled
openapi.yaml/mintlify/openapi.yamlviamake build, and documented the three wire-only fields pluspurposeOfPaymentin the two affected MDX pages.Compatibility
Additive and non-breaking — every new property is optional and nothing existing changed, so
info.versionis unchanged.Verified against the same gate CI runs:
make lintexits 0 ("Woohoo! Your API description is valid. 🎉"). The remainingschema-properties-have-examples/-descriptionsfindings 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 onlymake lint— exit 0, no findings onUsdAccountInfoBaseorTransferOutRequestoasdiff breaking --fail-on ERR— 0 breaking changes