chore: Sync account schemas

[lightspark-copybara]

Auto-synced account schemas.

These schemas are generated from VASP adapter field definitions in sparkcore.

Synced schemas:

• common/ — per-currency account info, beneficiary, and payment account schemas
• common/PaymentInstructions.yaml — payment instructions oneOf (new currencies added)
• external_accounts/ — per-currency external account schemas (reference common/)

Please review the changes before merging.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
grid-flow-builder	Ready	Preview, Comment	May 13, 2026 10:31pm

[github-actions]

✱ Stainless preview builds for grid

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

kotlin

fix(types): remove bankName field from COP account models

openapi

feat(api): remove bankName field from COP account types

python

fix(types): remove bank_name field from CopAccountInfo and CopExternalAccountCreateInfo

typescript

fix(types): remove bankName field from COP account types

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

✅ grid-python studio · code · diff

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

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

✅ grid-kotlin studio · code · diff

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

✅ grid-openapi studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
generate ❗

✅ grid-typescript studio · code · diff

Your SDK build had at least one "error" diagnostic, but this did not represent a regression.
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-05-13 22:37:46 UTC

[greptile-apps]

Greptile Summary

This PR syncs the COP (Colombian Peso) account schemas from sparkcore VASP adapter definitions, removing the bankName field from CopAccountInfoBase and simplifying several field descriptions across CopAccountInfoBase and CopBeneficiary. Both the source files (openapi/components/schemas/common/) and the generated bundles (openapi.yaml, mintlify/openapi.yaml) are updated consistently.

• CopAccountInfoBase: bankName is removed from the schema and from the BANK_TRANSFER required-fields list in the description; the example object is updated but now combines fields from two mutually exclusive payment rails.
• CopBeneficiary: documentType and documentNumber descriptions are shortened, removing the per-code enum explanations (CC, CE, TI, NIT, PP) that were the only inline reference for what each value means.

Confidence Score: 4/5

Safe to merge; changes are a straightforward schema sync with no structural breakage.

The removal of bankName and the description simplifications are intentional syncs from the backend source of truth. The two flagged items — a mixed-rails example object and the loss of per-code explanations for Colombian document types — are documentation quality concerns rather than functional defects, but they do reduce the schema's usefulness for developers integrating the COP rails.

openapi/components/schemas/common/CopAccountInfoBase.yaml (mixed-rails example) and openapi/components/schemas/common/CopBeneficiary.yaml (enum description loss) are worth a second look before merging.

Important Files Changed

Filename	Overview
openapi/components/schemas/common/CopAccountInfoBase.yaml	Removes bankName field and simplifies field descriptions; example now mixes BANK_TRANSFER and MOBILE_MONEY fields in a single object.
openapi/components/schemas/common/CopBeneficiary.yaml	Simplifies documentType and documentNumber descriptions, losing all per-enum-value explanations (CC, CE, TI, NIT, PP meanings).
openapi.yaml	Generated bundle — mirrors source schema changes identically; no independent issues.
mintlify/openapi.yaml	Mintlify-specific generated bundle — identical changes to openapi.yaml; no independent issues.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[CopAccountInfoBase] --> B{paymentRails}
    B -->|BANK_TRANSFER| C["accountNumber\nbankAccountType\n(bankName removed)"]
    B -->|MOBILE_MONEY| D["phoneNumber\n(Nequi / Daviplata)"]
    A --> E[CopAccountInfo]
    E --> F[CopExternalAccountInfo]
    G[CopBeneficiary] --> H["name / address\ndocumentType: CC|CE|TI|NIT|PP\ndocumentNumber"]

Loading

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
openapi/components/schemas/common/CopBeneficiary.yaml:32
**Loss of enum value explanations for `documentType`**

The previous description explained what each enum value stands for in plain language (e.g. "CC: Cédula de Ciudadanía, CE: Cédula de Extranjería, TI: Tarjeta de Identidad, NIT: Número de Identificación Tributaria, PP: Passport"). The replacement — `"Identity document type (Colombia)"` — leaves API consumers with five opaque codes and no inline guidance on which to send. The same change is mirrored in `openapi.yaml` and `mintlify/openapi.yaml`.

### Issue 2 of 2
openapi/components/schemas/common/CopAccountInfoBase.yaml:32-36
The example object now mixes fields from two mutually exclusive payment rails — `accountNumber` and `bankAccountType` are for `BANK_TRANSFER`, while `phoneNumber` is for `MOBILE_MONEY`. A single example object representing both rails simultaneously is not a valid real-world request and could confuse API consumers about how to construct their payloads.

```suggestion
example:
  accountType: COP_ACCOUNT
  accountNumber: '1234567890'
  bankAccountType: CHECKING
```

_{Reviews (1): Last reviewed commit: "chore: Sync account schemas" | Re-trigger Greptile}

[greptile-apps]

Loss of enum value explanations for documentType

The previous description explained what each enum value stands for in plain language (e.g. "CC: Cédula de Ciudadanía, CE: Cédula de Extranjería, TI: Tarjeta de Identidad, NIT: Número de Identificación Tributaria, PP: Passport"). The replacement — "Identity document type (Colombia)" — leaves API consumers with five opaque codes and no inline guidance on which to send. The same change is mirrored in openapi.yaml and mintlify/openapi.yaml.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/common/CopBeneficiary.yaml
Line: 32

Comment:
**Loss of enum value explanations for `documentType`**

The previous description explained what each enum value stands for in plain language (e.g. "CC: Cédula de Ciudadanía, CE: Cédula de Extranjería, TI: Tarjeta de Identidad, NIT: Número de Identificación Tributaria, PP: Passport"). The replacement — `"Identity document type (Colombia)"` — leaves API consumers with five opaque codes and no inline guidance on which to send. The same change is mirrored in `openapi.yaml` and `mintlify/openapi.yaml`.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

The example object now mixes fields from two mutually exclusive payment rails — accountNumber and bankAccountType are for BANK_TRANSFER, while phoneNumber is for MOBILE_MONEY. A single example object representing both rails simultaneously is not a valid real-world request and could confuse API consumers about how to construct their payloads.

Suggested change

	example:
	accountType: COP_ACCOUNT
	bankName: Bancolombia
	accountNumber: '1234567890'
	bankAccountType: CHECKING
	phoneNumber: '+1234567890'
	example:
	accountType: COP_ACCOUNT
	accountNumber: '1234567890'
	bankAccountType: CHECKING

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/common/CopAccountInfoBase.yaml
Line: 32-36

Comment:
The example object now mixes fields from two mutually exclusive payment rails — `accountNumber` and `bankAccountType` are for `BANK_TRANSFER`, while `phoneNumber` is for `MOBILE_MONEY`. A single example object representing both rails simultaneously is not a valid real-world request and could confuse API consumers about how to construct their payloads.

```suggestion
example:
  accountType: COP_ACCOUNT
  accountNumber: '1234567890'
  bankAccountType: CHECKING
```

How can I resolve this? If you propose a fix, please make it concise.