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	Apr 23, 2026 10:09pm

[github-actions]

✱ Stainless preview builds

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

kotlin

feat(api): add bankName fields, add bankAccountType to GTQ, remove phoneNumber, update types

openapi

fix(types): update required fields across USD/GTQ/COP/PEN account and beneficiary types

python

fix(types): update field requirements across beneficiaries, add bank_name to account types

typescript

fix(types): add bankName to BDT/EGP/GHS/GTQ/JMD/PKR, update USD/COP/GTQ requirements

⚠️ grid-openapi studio · code

Your SDK build had at least one "error" diagnostic.
generate ❗

⚠️ grid-kotlin studio · code

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

⚠️ grid-typescript studio · code

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

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

⚠️ grid-python studio · code

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

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

---

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-23 22:44:01 UTC

[greptile-apps]

Greptile Summary

This auto-synced PR updates 42 account schema files, adding schema-level example blocks across all currency AccountInfoBase schemas and making several structural changes to required fields and enums sourced from sparkcore's VASP adapter definitions.

The bulk of the changes (example additions, new bankName required fields for BDT, EGP, GHS, JMD, PKR, COP, GTQ) are additive and straightforward, but a few changes represent breaking API contracts that existing integrators may not be prepared for:

• UsdAccountInfoBase: bankAccountType (CHECKING/SAVINGS, previously noted as "Required for certain corridors e.g. El Salvador") is removed with no replacement.
• UsdBeneficiary: address, birthDate, and nationality are now required — existing payloads omitting these will fail validation.
• CopBeneficiary: documentNumber and documentType are now required; countryOfResidence is no longer required.
• UsdAccountInfo, CopAccountInfo, GtqAccountInfo: BANK_TRANSFER / MOBILE_MONEY enum values removed.

Confidence Score: 4/5

Safe to merge if the backend already reflects these breaking changes; needs human confirmation that corridor migrations (especially USD/El Salvador bankAccountType) are handled.

Three P1 findings cover breaking schema changes to required fields and enum values across USD, COP, and GTQ schemas. The changes are intentional (generated from sparkcore), but the removal of bankAccountType from UsdAccountInfoBase in particular needs explicit confirmation that no active corridor relies on it.

UsdAccountInfoBase.yaml, UsdBeneficiary.yaml, and CopBeneficiary.yaml carry the highest-impact breaking changes and warrant explicit sign-off.

Important Files Changed

Filename	Overview
openapi/components/schemas/common/UsdAccountInfoBase.yaml	Removes bankAccountType (CHECKING/SAVINGS) field previously described as required for certain corridors (e.g., El Salvador); adds schema-level example.
openapi/components/schemas/common/UsdAccountInfo.yaml	Removes BANK_TRANSFER from the payment method enum — a breaking change for any client currently using that value.
openapi/components/schemas/common/UsdBeneficiary.yaml	Adds address, birthDate, and nationality to the required list — breaking change for existing USD beneficiary payloads.
openapi/components/schemas/common/CopBeneficiary.yaml	Swaps countryOfResidence out of required in favour of documentNumber and documentType; reorders address and document fields — breaking change for existing integrations.
openapi/components/schemas/common/CopAccountInfoBase.yaml	Removes phoneNumber field entirely and reorders required fields; adds bankName with length constraints and a schema-level example.
openapi/components/schemas/common/CopAccountInfo.yaml	Removes MOBILE_MONEY from the payment method enum for COP accounts.
openapi/components/schemas/common/GtqAccountInfoBase.yaml	Replaces phoneNumber with bankAccountType (CHECKING/SAVINGS enum) and adds required bankName; significantly changes the schema shape for GTQ accounts.
openapi/components/schemas/common/GtqAccountInfo.yaml	Removes MOBILE_MONEY from the payment method enum for GTQ accounts, aligned with the GTQ account info restructure.
openapi/components/schemas/common/GtqBeneficiary.yaml	Adds phoneNumber to the required list — breaking change for existing GTQ beneficiary payloads that omit phone.
openapi/components/schemas/common/EgpAccountInfoBase.yaml	Adds required bankName field; inline IBAN example uses a German IBAN rather than an Egypt-specific one.
openapi/components/schemas/common/PkrAccountInfoBase.yaml	Adds required bankName; the optional iban property example uses a German IBAN despite Pakistan not using the IBAN system.
openapi.yaml	Generated bundle — reflects all source schema changes; includes the same breaking changes (bankAccountType removal, UsdBeneficiary new required fields, CopBeneficiary required swap, enum removals).

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    subgraph Removed["⛔ Removed / Breaking"]
        A["UsdAccountInfoBase\n– bankAccountType field removed\n(was: CHECKING | SAVINGS)"]
        B["UsdAccountInfo\n– BANK_TRANSFER enum removed"]
        C["CopAccountInfo / GtqAccountInfo\n– MOBILE_MONEY enum removed"]
        D["CopAccountInfoBase\n– phoneNumber field removed"]
    end

    subgraph AddedRequired["⚠️ New Required Fields"]
        E["UsdBeneficiary\n+ address, birthDate, nationality"]
        F["CopBeneficiary\n+ documentNumber, documentType\n– countryOfResidence (no longer required)"]
        G["GtqBeneficiary\n+ phoneNumber"]
        H["BDT / EGP / GHS / GTQ / JMD / PKR / COP\n+ bankName (required)"]
    end

    subgraph AddedOptional["✅ Additive / Examples"]
        I["30+ AccountInfoBase schemas\n+ schema-level example block"]
        J["GtqAccountInfoBase\nphoneNumber → bankAccountType enum"]
    end

    Removed --> AddedRequired
    AddedRequired --> AddedOptional

Loading

Comments Outside Diff (5)

1. openapi/components/schemas/common/UsdAccountInfoBase.yaml, line 1-27 (link)

   bankAccountType removed without replacement

   The bankAccountType field (CHECKING/SAVINGS) was previously described as "Required for certain corridors (e.g., El Salvador)" and has been removed entirely. Clients using USD accounts for corridors that depend on this distinction now have no way to express the account type, which may silently break routing for those corridors unless the backend now derives it differently.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: openapi/components/schemas/common/UsdAccountInfoBase.yaml
   Line: 1-27
   
   Comment:
   **`bankAccountType` removed without replacement**
   
   The `bankAccountType` field (CHECKING/SAVINGS) was previously described as "Required for certain corridors (e.g., El Salvador)" and has been removed entirely. Clients using USD accounts for corridors that depend on this distinction now have no way to express the account type, which may silently break routing for those corridors unless the backend now derives it differently.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

2. openapi/components/schemas/common/UsdBeneficiary.yaml, line 1-8 (link)

   Three new fields added to required

   address, birthDate, and nationality are now required for UsdBeneficiary. Any existing API consumer that builds a USD beneficiary payload without these fields will receive a validation error after this sync, making this a breaking change for in-flight integrations targeting the USD corridor.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: openapi/components/schemas/common/UsdBeneficiary.yaml
   Line: 1-8
   
   Comment:
   **Three new fields added to `required`**
   
   `address`, `birthDate`, and `nationality` are now required for `UsdBeneficiary`. Any existing API consumer that builds a USD beneficiary payload without these fields will receive a validation error after this sync, making this a breaking change for in-flight integrations targeting the USD corridor.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

3. openapi/components/schemas/common/CopBeneficiary.yaml, line 1-7 (link)

   Required fields replaced — countryOfResidence dropped, documentNumber/documentType added

   countryOfResidence is no longer required while documentNumber and documentType are now mandatory. Existing clients that omit document fields but supply countryOfResidence will begin failing validation. Please confirm this matches the live backend requirement change and that a migration path or communication to existing integrators is planned.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: openapi/components/schemas/common/CopBeneficiary.yaml
   Line: 1-7
   
   Comment:
   **Required fields replaced — `countryOfResidence` dropped, `documentNumber`/`documentType` added**
   
   `countryOfResidence` is no longer required while `documentNumber` and `documentType` are now mandatory. Existing clients that omit document fields but supply `countryOfResidence` will begin failing validation. Please confirm this matches the live backend requirement change and that a migration path or communication to existing integrators is planned.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

4. openapi/components/schemas/common/EgpAccountInfoBase.yaml, line 21-39 (link)

   German IBAN used as inline example for an Egyptian account

   Both the iban property-level example (line 24) and the schema-level example block reference DE89370400440532013000, which is a German IBAN. Egyptian IBANs begin with EG and are 29 characters long; using a German IBAN may confuse integrators. Consider substituting a realistic EGP IBAN (e.g., EG380019000500000000263180002).

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: openapi/components/schemas/common/EgpAccountInfoBase.yaml
   Line: 21-39
   
   Comment:
   **German IBAN used as inline example for an Egyptian account**
   
   Both the `iban` property-level example (line 24) and the schema-level `example` block reference `DE89370400440532013000`, which is a German IBAN. Egyptian IBANs begin with `EG` and are 29 characters long; using a German IBAN may confuse integrators. Consider substituting a realistic EGP IBAN (e.g., `EG380019000500000000263180002`).
   
   How can I resolve this? If you propose a fix, please make it concise.

   

5. openapi/components/schemas/common/PkrAccountInfoBase.yaml, line 22-28 (link)

   German IBAN used as example; Pakistan does not use IBAN

   The inline property example for iban (line 25) is DE89370400440532013000, a German IBAN. Pakistan is not part of the IBAN scheme, so this field and its example may mislead integrators. If the field is legacy/optional for edge cases, a comment or description clarifying the context would help.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: openapi/components/schemas/common/PkrAccountInfoBase.yaml
   Line: 22-28
   
   Comment:
   **German IBAN used as example; Pakistan does not use IBAN**
   
   The inline property `example` for `iban` (line 25) is `DE89370400440532013000`, a German IBAN. Pakistan is not part of the IBAN scheme, so this field and its example may mislead integrators. If the field is legacy/optional for edge cases, a comment or description clarifying the context would help.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

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

Comment:
**`bankAccountType` removed without replacement**

The `bankAccountType` field (CHECKING/SAVINGS) was previously described as "Required for certain corridors (e.g., El Salvador)" and has been removed entirely. Clients using USD accounts for corridors that depend on this distinction now have no way to express the account type, which may silently break routing for those corridors unless the backend now derives it differently.

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/UsdBeneficiary.yaml
Line: 1-8

Comment:
**Three new fields added to `required`**

`address`, `birthDate`, and `nationality` are now required for `UsdBeneficiary`. Any existing API consumer that builds a USD beneficiary payload without these fields will receive a validation error after this sync, making this a breaking change for in-flight integrations targeting the USD corridor.

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: 1-7

Comment:
**Required fields replaced — `countryOfResidence` dropped, `documentNumber`/`documentType` added**

`countryOfResidence` is no longer required while `documentNumber` and `documentType` are now mandatory. Existing clients that omit document fields but supply `countryOfResidence` will begin failing validation. Please confirm this matches the live backend requirement change and that a migration path or communication to existing integrators is planned.

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/EgpAccountInfoBase.yaml
Line: 21-39

Comment:
**German IBAN used as inline example for an Egyptian account**

Both the `iban` property-level example (line 24) and the schema-level `example` block reference `DE89370400440532013000`, which is a German IBAN. Egyptian IBANs begin with `EG` and are 29 characters long; using a German IBAN may confuse integrators. Consider substituting a realistic EGP IBAN (e.g., `EG380019000500000000263180002`).

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/PkrAccountInfoBase.yaml
Line: 22-28

Comment:
**German IBAN used as example; Pakistan does not use IBAN**

The inline property `example` for `iban` (line 25) is `DE89370400440532013000`, a German IBAN. Pakistan is not part of the IBAN scheme, so this field and its example may mislead integrators. If the field is legacy/optional for edge cases, a comment or description clarifying the context would help.

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

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