Add bankAccountType to USD, bankName/documentType/documentNumber to COP, and COMPANY_LEGAL_NAME field name

[matthappens]

TL;DR

Expanded the OpenAPI schema with new fields for COP accounts, USD account info, and customer field definitions.

What changed?

• Added bankName as a required field to CopAccountInfoBase, capturing the name of the bank for COP accounts.
• Added documentType and documentNumber fields to CopBeneficiary, allowing identity document information (e.g., national ID, passport) to be associated with a beneficiary.
• Added bankAccountType (CHECKING or SAVINGS) to UsdAccountInfoBase, required for certain corridors such as El Salvador.
• Added COMPANY_LEGAL_NAME as a valid enum value to CustomerInfoFieldName, enabling platforms to capture a company's legal name as a customer info field.

How to test?

• Validate that COP account creation requests require bankName and that the field is correctly documented in the API reference.
• Confirm that documentType and documentNumber can be submitted as part of a COP beneficiary payload.
• Test USD account creation for El Salvador corridors to verify that bankAccountType is accepted and enforced where required.
• Verify that COMPANY_LEGAL_NAME is accepted as a valid CustomerInfoFieldName value in relevant customer info requests.

Why make this change?

These additions support expanded corridor requirements and compliance needs. Certain payment corridors (e.g., El Salvador) require bank account type information for USD transfers, COP beneficiaries may need identity document details for regulatory purposes, and COMPANY_LEGAL_NAME is needed to capture legal entity information for business customers.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ready	Preview, Comment	Apr 22, 2026 4:48pm

[matthappens]

• Add bankAccountType to USD, bankName/documentType/documentNumber to COP, and COMPANY_LEGAL_NAME field name #352 👈 (View in Graphite)
• main

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

[github-actions]

✱ Stainless preview builds

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

kotlin

feat(api): add COMPANY_LEGAL_NAME to CustomerInfoFieldName

openapi

feat(api): add COMPANY_LEGAL_NAME to CounterpartyFieldType enum

python

feat(api): add COMPANY_LEGAL_NAME to CustomerInfoFieldName

typescript

feat(api): add COMPANY_LEGAL_NAME to CustomerInfoFieldName in config

✅ grid-openapistudio · code

Your SDK build had at least one "note" diagnostic.
generate ✅

✅ grid-pythonstudio · code

Your SDK build had at least one "note" diagnostic.
generate ✅ → build ✅ → lint ✅ → test ✅

pip install https://pkg.stainless.com/s/grid-python/022b1d31804b0ec00a8450e8dac8a6fe33e122fd/grid-0.0.1-py3-none-any.whl

✅ grid-typescriptstudio · code

Your SDK build had at least one "note" diagnostic.
generate ✅ → build ✅ → lint ✅ → test ✅

npm install https://pkg.stainless.com/s/grid-typescript/fec872f2ba71d595e24c6b760ad152669b8e895d/dist.tar.gz

✅ grid-kotlinstudio · code

Your SDK build had at least one "note" diagnostic.
generate ✅ → build ✅ → 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-04-22 17:18:53 UTC

[greptile-apps]

Greptile Summary

This PR extends the OpenAPI schema with new fields across four components: bankName (required) on CopAccountInfoBase, documentType/documentNumber (optional) on CopBeneficiary, bankAccountType (optional) on UsdAccountInfoBase, and COMPANY_LEGAL_NAME on the CustomerInfoFieldName enum — supporting expanded corridor requirements and compliance needs.

• Breaking change risk: Making bankName required on CopAccountInfoBase will break any existing COP account creation client not yet passing this field. Confirm whether existing integrations have been updated or whether a migration period is needed before enforcing this in the schema.

Confidence Score: 4/5

Safe to merge once the breaking-change implications of the required bankName field are confirmed or addressed.

One P1 concern: adding bankName to required in CopAccountInfoBase is a breaking schema change that could silently break existing COP account creation clients. All other changes are additive and low-risk. Score is 4 pending confirmation that existing consumers are ready for this requirement.

openapi/components/schemas/common/CopAccountInfoBase.yaml — requires attention due to the newly required bankName field and its potential for breaking existing clients.

Important Files Changed

Filename	Overview
openapi/components/schemas/common/CopAccountInfoBase.yaml	Adds bankName as a required field — a potentially breaking change for existing COP account creation clients; also lacks string length constraints on the new field.
openapi/components/schemas/common/CopBeneficiary.yaml	Adds optional documentType and documentNumber fields; documentType is an unconstrained string that would benefit from an enum of valid values.
openapi/components/schemas/common/UsdAccountInfoBase.yaml	Adds optional bankAccountType enum (CHECKING/SAVINGS) for corridor-specific requirements; clean change, consistent with COP account pattern.
openapi/components/schemas/customers/CustomerInfoFieldName.yaml	Adds COMPANY_LEGAL_NAME to the enum — clean, additive change with no issues.
openapi.yaml	Generated bundle reflecting all source schema changes; consistent with component-level edits.
mintlify/openapi.yaml	Mintlify-specific generated bundle; identical changes to openapi.yaml, consistent with source changes.

Entity Relationship Diagram

%%{init: {'theme': 'neutral'}}%%
erDiagram
CopAccountInfoBase {
string accountType "enum: COP_ACCOUNT"
string accountNumber "minLength:1, maxLength:34"
string bankAccountType "enum: CHECKING|SAVINGS"
string bankName "NEW - required"
string phoneNumber "minLength:7, maxLength:15"
}
CopBeneficiary {
string beneficiaryType "enum: INDIVIDUAL"
string fullName
string birthDate
string nationality
string email
string phoneNumber
string countryOfResidence
string documentType "NEW - optional, no enum"
string documentNumber "NEW - optional"
object address
}
UsdAccountInfoBase {
string accountType "enum: USD_ACCOUNT"
string accountNumber "minLength:1, maxLength:34"
string routingNumber "pattern: 9 digits"
string bankAccountType "NEW - optional, enum: CHECKING|SAVINGS"
}
CustomerInfoFieldName {
string enum "...BUSINESS_TYPE"
string COMPANY_LEGAL_NAME "NEW"
}
CopAccountInfoBase ||--o{ CopBeneficiary : "used with"

Loading

Prompt To Fix All With AI

This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 6
Comment:
**Potentially breaking change: `bankName` added as required**
Adding `bankName` to the `required` array is a breaking schema change for existing API consumers creating COP accounts — any client that doesn't already pass this field will now fail validation. If the backend enforcement is being introduced simultaneously, existing integrations will break without a migration period. Consider whether this should be phased in (e.g., optional first, then required) or whether existing clients have already been notified/updated.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: openapi/components/schemas/common/CopBeneficiary.yaml
Line: 30-32
Comment:
**`documentType` should use an enum for valid values**`documentType` is defined as an unconstrained `string`. Without an enum, any arbitrary value (e.g., `"foobar"`) is schema-valid, which makes interoperability and validation harder. Other document-type fields in payment APIs typically enumerate accepted values. Consider adding an enum of known document types such as `NATIONAL_ID`, `PASSPORT`, `DRIVERS_LICENSE`, etc.
```suggestion documentType: type: string description: The type of identity document enum: - NATIONAL_ID - PASSPORT - DRIVERS_LICENSE```
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 24-26
Comment:
**`bankName` has no string length constraints**
Unlike `accountNumber` (`maxLength: 34`) and `phoneNumber` (`minLength: 7`, `maxLength: 15`), `bankName` has no length bounds. Consider adding `minLength: 1` and a reasonable `maxLength` to prevent empty strings or excessively long values from being submitted.
How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (2): Last reviewed commit: "Add Thunes COP/USD fields for bankName, ..." | Re-trigger Greptile}

[matthappens]

@greptile please review

[greptile-apps]

Potentially breaking change: bankName added as required

Adding bankName to the required array is a breaking schema change for existing API consumers creating COP accounts — any client that doesn't already pass this field will now fail validation. If the backend enforcement is being introduced simultaneously, existing integrations will break without a migration period. Consider whether this should be phased in (e.g., optional first, then required) or whether existing clients have already been notified/updated.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 6
Comment:
**Potentially breaking change: `bankName` added as required**
Adding `bankName` to the `required` array is a breaking schema change for existing API consumers creating COP accounts — any client that doesn't already pass this field will now fail validation. If the backend enforcement is being introduced simultaneously, existing integrations will break without a migration period. Consider whether this should be phased in (e.g., optional first, then required) or whether existing clients have already been notified/updated.
How can I resolve this? If you propose a fix, please make it concise.

[matthappens]

this is a clean change, we have no existing Cop accounts

[jklein24]

I could have sworn we have this somewhere, so I searched for "CHECKING" in the api and I saw that we only have it (incorrectly) in the example for external account creation as accountCategory. Can you update those examples too for both platform and customer external account creation?

[matthappens]

can do!

[matthappens]

Merge activity

• Apr 22, 5:11 PM UTC: A user started a stack merge that includes this pull request via Graphite.
• Apr 22, 5:12 PM UTC: @matthappens merged this pull request with Graphite.