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 1, 2026 11:42pm

[github-actions]

✱ Stainless preview builds

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

kotlin

feat(api): remove document/bank fields, add phoneNumber/MOBILE_MONEY to COP types

openapi

fix(types): make fields optional, add phoneNumber/MOBILE_MONEY to CopAccount/Beneficiary

python

feat(api): add phone_number/mobile_money, remove bank/document fields in cop types

typescript

feat(api): add mobile money support to COP external accounts

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

✅ grid-openapi studio · code · diff

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

✅ 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-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/67d2d6a39d3375fd4bb386121b80bc42c3094b01/grid-0.0.1-py3-none-any.whl

✅ 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 ✅

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

---

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-01 23:48:07 UTC

[greptile-apps]

Greptile Summary

This PR syncs COP (Colombian peso) account schemas from sparkcore: CopAccountInfoBase is restructured to support both BANK_TRANSFER (using accountNumber) and MOBILE_MONEY (using phoneNumber) payment rails, and CopBeneficiary drops documentType/documentNumber as required and defined fields.

• The removal of documentType and documentNumber from CopBeneficiary.properties is a breaking change — existing consumers who submit these identity document fields will no longer have them documented or validated, and requests may silently drop them.
• CopAccountInfoBase now has only accountType in required; the per-rail conditional requirements (accountNumber / phoneNumber) are documented in prose only and will not be enforced by schema validators.

Confidence Score: 3/5

Hold for confirmation that backend no longer requires COP document identity fields and that existing integrations are not broken.

A P1 finding (breaking removal of documentType/documentNumber from CopBeneficiary properties) requires confirmation before merge, pulling the score below the P1 ceiling of 4. The conditional-required enforcement gap and misleading example are P2s that don't further lower the ceiling but add to overall concern.

openapi/components/schemas/common/CopBeneficiary.yaml — verify document field removal is intentional and backend-coordinated. openapi/components/schemas/common/CopAccountInfoBase.yaml — consider formal oneOf/if-then-else for conditional required fields.

Important Files Changed

Filename	Overview
openapi/components/schemas/common/CopAccountInfoBase.yaml	Replaced bankName/bankAccountType with phoneNumber; removed accountNumber/bankAccountType from required; description-only conditional required creates a schema enforcement gap, and the example misleadingly shows both mutually exclusive fields together.
openapi/components/schemas/common/CopBeneficiary.yaml	documentType and documentNumber removed from both required and properties — a potentially breaking change for existing COP beneficiary submissions relying on identity document fields.
openapi/components/schemas/common/CopAccountInfo.yaml	Added MOBILE_MONEY to paymentRails enum — straightforward additive change.
openapi.yaml	Auto-generated bundle reflecting source schema changes — mirrors CopAccountInfoBase and CopBeneficiary modifications correctly.
mintlify/openapi.yaml	Auto-generated Mintlify bundle — identical diff to openapi.yaml, reflecting the same COP schema changes.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[CopAccountInfo] -->|allOf| B[CopAccountInfoBase]
    A -->|allOf| C[paymentRails array]
    C --> D{paymentRails value}
    D -->|BANK_TRANSFER| E["accountNumber (required by docs)"]
    D -->|MOBILE_MONEY| F["phoneNumber (required by docs)"]
    B --> G[accountType: COP_ACCOUNT]
    B --> E
    B --> F

Loading

Comments Outside Diff (1)

1. openapi/components/schemas/common/CopBeneficiary.yaml, line 28-31 (link)

   Breaking removal of documentType and documentNumber from properties

   documentType and documentNumber were previously required fields on CopBeneficiary and are now removed entirely from both required and properties. Existing API consumers who currently populate these fields (e.g., national ID, passport number) will no longer see them documented in the schema, and any client code referencing these fields will silently stop sending them. If the backend enforces document identity for COP payments, those requests will begin failing without any schema-level signal to the caller.

   Please confirm the backend no longer requires or processes these fields before merging.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: openapi/components/schemas/common/CopBeneficiary.yaml
   Line: 28-31
   
   Comment:
   **Breaking removal of `documentType` and `documentNumber` from properties**
   
   `documentType` and `documentNumber` were previously required fields on `CopBeneficiary` and are now removed entirely from both `required` and `properties`. Existing API consumers who currently populate these fields (e.g., national ID, passport number) will no longer see them documented in the schema, and any client code referencing these fields will silently stop sending them. If the backend enforces document identity for COP payments, those requests will begin failing without any schema-level signal to the caller.
   
   Please confirm the backend no longer requires or processes these fields before merging.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

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

---

### Issue 1 of 3
openapi/components/schemas/common/CopAccountInfoBase.yaml:26-29
**Misleading example combines mutually exclusive fields**

The `example` object includes both `accountNumber` and `phoneNumber` simultaneously, but these fields are mutually exclusive by payment rail (`BANK_TRANSFER` uses `accountNumber`, `MOBILE_MONEY` uses `phoneNumber`). An API consumer following this example would supply both fields regardless of their chosen payment rail, which is confusing and doesn't model the actual expected usage.

Consider splitting into two separate examples, or picking one canonical example (e.g., the `BANK_TRANSFER` case).

### Issue 2 of 3
openapi/components/schemas/common/CopBeneficiary.yaml:28-31
**Breaking removal of `documentType` and `documentNumber` from properties**

`documentType` and `documentNumber` were previously required fields on `CopBeneficiary` and are now removed entirely from both `required` and `properties`. Existing API consumers who currently populate these fields (e.g., national ID, passport number) will no longer see them documented in the schema, and any client code referencing these fields will silently stop sending them. If the backend enforces document identity for COP payments, those requests will begin failing without any schema-level signal to the caller.

Please confirm the backend no longer requires or processes these fields before merging.

### Issue 3 of 3
openapi/components/schemas/common/CopAccountInfoBase.yaml:1-8
**Conditional required not enforced at schema level**

The description documents that `accountNumber` is required for `BANK_TRANSFER` and `phoneNumber` for `MOBILE_MONEY`, but neither field appears in the `required` array — only `accountType` does. Schema validators (clients, linters, request-validation middleware) will not enforce these conditional requirements. OpenAPI 3.1 supports `if/then/else` or `oneOf` discrimination to formally encode this constraint; OpenAPI 3.0 can use `oneOf` to model the two variants. As-is, missing a required payment-rail-specific field will silently pass schema validation and only fail at runtime.

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

[greptile-apps]

Misleading example combines mutually exclusive fields

The example object includes both accountNumber and phoneNumber simultaneously, but these fields are mutually exclusive by payment rail (BANK_TRANSFER uses accountNumber, MOBILE_MONEY uses phoneNumber). An API consumer following this example would supply both fields regardless of their chosen payment rail, which is confusing and doesn't model the actual expected usage.

Consider splitting into two separate examples, or picking one canonical example (e.g., the BANK_TRANSFER case).

Prompt To Fix With AI

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

Comment:
**Misleading example combines mutually exclusive fields**

The `example` object includes both `accountNumber` and `phoneNumber` simultaneously, but these fields are mutually exclusive by payment rail (`BANK_TRANSFER` uses `accountNumber`, `MOBILE_MONEY` uses `phoneNumber`). An API consumer following this example would supply both fields regardless of their chosen payment rail, which is confusing and doesn't model the actual expected usage.

Consider splitting into two separate examples, or picking one canonical example (e.g., the `BANK_TRANSFER` case).

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

[greptile-apps]

Conditional required not enforced at schema level

The description documents that accountNumber is required for BANK_TRANSFER and phoneNumber for MOBILE_MONEY, but neither field appears in the required array — only accountType does. Schema validators (clients, linters, request-validation middleware) will not enforce these conditional requirements. OpenAPI 3.1 supports if/then/else or oneOf discrimination to formally encode this constraint; OpenAPI 3.0 can use oneOf to model the two variants. As-is, missing a required payment-rail-specific field will silently pass schema validation and only fail at runtime.

Prompt To Fix With AI

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

Comment:
**Conditional required not enforced at schema level**

The description documents that `accountNumber` is required for `BANK_TRANSFER` and `phoneNumber` for `MOBILE_MONEY`, but neither field appears in the `required` array — only `accountType` does. Schema validators (clients, linters, request-validation middleware) will not enforce these conditional requirements. OpenAPI 3.1 supports `if/then/else` or `oneOf` discrimination to formally encode this constraint; OpenAPI 3.0 can use `oneOf` to model the two variants. As-is, missing a required payment-rail-specific field will silently pass schema validation and only fail at runtime.

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