Skip to content

chore: Sync account schemas#346

Closed
lightspark-copybara[bot] wants to merge 1 commit intomainfrom
auto/sync-grid-schemas-20260416-172831
Closed

chore: Sync account schemas#346
lightspark-copybara[bot] wants to merge 1 commit intomainfrom
auto/sync-grid-schemas-20260416-172831

Conversation

@lightspark-copybara
Copy link
Copy Markdown
Contributor

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
Copy link
Copy Markdown

vercel Bot commented Apr 16, 2026

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

Project Deployment Actions Updated (UTC)
grid-flow-builder Ready Ready Preview, Comment Apr 16, 2026 5:29pm

Request Review

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented Apr 16, 2026

✱ Stainless preview builds

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

kotlin

feat(api): add bankName to account types, phoneNumber to USD, MOBILE_MONEY payment rail

openapi

feat(types): add bankName/phoneNumber to account types, require paymentRails across currencies

python

feat(api): add bank_name across account types, phone_number/payment_rails to USD

typescript

feat(api): add bankName/phoneNumber fields, MOBILE_MONEY rail to account types

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

grid-typescript studio · code · diff

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

npm install https://pkg.stainless.com/s/grid-typescript/f808debea256e7c4eacab7c3fbfcee66d76cc856/dist.tar.gz
grid-kotlin studio · code · diff

Your SDK build had at least one new note diagnostic, which is a regression from the base state.
generate ✅build ✅lint ✅test ✅

New diagnostics (59 note)
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
💡 Schema/EnumHasOneMember: Confirm intentional use of `enum` with single member.
grid-openapi studio · code · diff

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

grid-python studio · code · diff

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

pip install https://pkg.stainless.com/s/grid-python/12664a308ea9819badf44091ececa5cf3e8db27f/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-16 17:34:14 UTC

@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps Bot commented Apr 16, 2026

Greptile Summary

This PR syncs 34 *AccountInfo schemas from sparkcore, replacing the previous allOf + base-schema composition pattern with fully self-contained inline schemas. Each schema now declares its own accountType discriminator, paymentRails enum, and all currency-specific fields with validation patterns. The *AccountInfoBase.yaml files remain in place and continue to be referenced by the corresponding ExternalAccountCreateInfo schemas, so the external-account create path is unaffected.

Confidence Score: 5/5

Safe to merge; all findings are P2 documentation quality issues that do not affect validation logic or API behaviour.

All remaining comments are P2 style suggestions (wrong example values) plus one P2 question about the USD phoneNumber required constraint. None of these affect runtime validation or break existing integrations.

EgpAccountInfo.yaml, PkrAccountInfo.yaml, DkkAccountInfo.yaml (wrong IBAN examples); MyrAccountInfo.yaml (wrong SWIFT country code in example); UsdAccountInfo.yaml (phoneNumber in required list for all rails).

Important Files Changed

Filename Overview
openapi/components/schemas/common/UsdAccountInfo.yaml Adds new MOBILE_MONEY rail and makes phoneNumber a required field for all USD accounts, which is non-standard for domestic transfers
openapi/components/schemas/common/EgpAccountInfo.yaml Refactored from allOf+base to standalone schema; optional iban/swiftCode fields use a German IBAN example instead of an Egyptian one
openapi/components/schemas/common/PkrAccountInfo.yaml Refactored to standalone schema; optional iban field uses a German IBAN example instead of a Pakistani one
openapi/components/schemas/common/DkkAccountInfo.yaml Refactored to standalone schema; iban example uses German IBAN instead of Danish IBAN
openapi/components/schemas/common/MyrAccountInfo.yaml Refactored to standalone schema; swiftCode example MABORUMMYYY contains country code RU (Russia) instead of MY (Malaysia)
openapi/components/schemas/common/AedAccountInfo.yaml Refactored from allOf+base to standalone schema; AED-specific IBAN pattern and SWIFT code constraints look correct
openapi/components/schemas/common/BrlAccountInfo.yaml Refactored to standalone schema with PIX-specific fields; pixKey, pixKeyType, and taxId constraints look correct
openapi/components/schemas/common/GbpAccountInfo.yaml Refactored to standalone schema; UK sort code (6 digits) and account number (8 digits) constraints are correct
openapi/components/schemas/common/XafAccountInfo.yaml Adds new region field with CM/CG enum for CFA franc zone; redundant pattern constraint alongside enum but non-breaking
openapi/components/schemas/common/XofAccountInfo.yaml Adds region field with BJ/CI/SN/TG enum for West African CFA franc zone; redundant pattern constraint alongside enum but non-breaking
openapi/components/schemas/common/InrAccountInfo.yaml Refactored to standalone schema with UPI vpa field; pattern and length constraints look appropriate
openapi/components/schemas/common/MxnAccountInfo.yaml Refactored to standalone schema with CLABE number (18 digits); constraints are correct for Mexican SPEI transfers

Class Diagram

%%{init: {'theme': 'neutral'}}%%
classDiagram
    class AccountInfo {
        +accountType: string
        +paymentRails: string[]
        +currency-specific fields
    }
    class AccountInfoBase {
        +accountType: string
        +currency-specific fields
    }
    class ExternalAccountCreateInfo {
        +beneficiary: Beneficiary
    }
    ExternalAccountCreateInfo --> AccountInfoBase : allOf ref (unchanged)
    note for AccountInfo "Previously: allOf + ref AccountInfoBase\nNow: fully inline (this PR)"
Loading

Fix All in Claude Code

Prompt To Fix All With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/EgpAccountInfo.yaml
Line: 30-31

Comment:
**Wrong IBAN example — German IBAN used for Egypt**

The `iban` example `DE89370400440532013000` is a German IBAN. An Egyptian IBAN starts with `EG` and is 29 characters. Developers using this as a reference will build incorrect integrations. The same copy-paste issue appears in `PkrAccountInfo.yaml` and `DkkAccountInfo.yaml`.

```suggestion
  iban:
    type: string
    description: The IBAN of the bank account
    example: EG380019000500000000263180002
    minLength: 15
    maxLength: 34
    pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
```

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/PkrAccountInfo.yaml
Line: 30-31

Comment:
**Wrong IBAN example — German IBAN used for Pakistan**

Same copy-paste issue as `EgpAccountInfo.yaml`: the example `DE89370400440532013000` is a German IBAN. Pakistani IBANs start with `PK` and are 24 characters (e.g., `PK36SCBL0000001123456702`).

```suggestion
  iban:
    type: string
    description: The IBAN of the bank account
    example: PK36SCBL0000001123456702
    minLength: 15
    maxLength: 34
    pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
```

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/DkkAccountInfo.yaml
Line: 19-20

Comment:
**IBAN example is German, not Danish**

The example `DE89370400440532013000` is a 22-character German IBAN. Danish IBANs start with `DK` and are 18 characters. Consumers of this API doc may attempt to validate or test with a wrong-length IBAN.

```suggestion
  iban:
    type: string
    description: The IBAN of the bank account
    example: DK5000400440116243
    minLength: 15
    maxLength: 34
    pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
```

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/MyrAccountInfo.yaml
Line: 30-31

Comment:
**SWIFT example has wrong country code for Malaysia**

`MABORUMMYYY` contains `RU` in the country-code position (characters 5–6) — that's Russia's ISO code, not Malaysia's (`MY`). Malaysian SWIFT codes should look like `MBBEMYKL` (Maybank). The pattern `^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$` won't catch this because it doesn't validate country codes.

```suggestion
  swiftCode:
    type: string
    description: The SWIFT/BIC code of the bank
    example: MBBEMYKL
    minLength: 8
    maxLength: 11
    pattern: ^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$
```

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/UsdAccountInfo.yaml
Line: 6-8

Comment:
**`phoneNumber` required for all USD payment rails**

`phoneNumber` is in the top-level `required` array, so it is mandatory even for pure domestic transfers (ACH, Wire, RTP, FedNow) where a phone number is not a banking requirement. If a USD bank account record in sparkcore can omit `phoneNumber` for those rails, API consumers receiving such a response will encounter a validation mismatch. Is this field only relevant for the new `MOBILE_MONEY` rail? If so, it should be optional (remove from `required`) with a note that it is required when `paymentRails` includes `MOBILE_MONEY`.

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

Comment on lines +30 to +31
description: The IBAN of the bank account
example: DE89370400440532013000
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Wrong IBAN example — German IBAN used for Egypt

The iban example DE89370400440532013000 is a German IBAN. An Egyptian IBAN starts with EG and is 29 characters. Developers using this as a reference will build incorrect integrations. The same copy-paste issue appears in PkrAccountInfo.yaml and DkkAccountInfo.yaml.

Suggested change
description: The IBAN of the bank account
example: DE89370400440532013000
iban:
type: string
description: The IBAN of the bank account
example: EG380019000500000000263180002
minLength: 15
maxLength: 34
pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/EgpAccountInfo.yaml
Line: 30-31

Comment:
**Wrong IBAN example — German IBAN used for Egypt**

The `iban` example `DE89370400440532013000` is a German IBAN. An Egyptian IBAN starts with `EG` and is 29 characters. Developers using this as a reference will build incorrect integrations. The same copy-paste issue appears in `PkrAccountInfo.yaml` and `DkkAccountInfo.yaml`.

```suggestion
  iban:
    type: string
    description: The IBAN of the bank account
    example: EG380019000500000000263180002
    minLength: 15
    maxLength: 34
    pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
```

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

Fix in Claude Code

Comment on lines +30 to +31
iban:
type: string
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Wrong IBAN example — German IBAN used for Pakistan

Same copy-paste issue as EgpAccountInfo.yaml: the example DE89370400440532013000 is a German IBAN. Pakistani IBANs start with PK and are 24 characters (e.g., PK36SCBL0000001123456702).

Suggested change
iban:
type: string
iban:
type: string
description: The IBAN of the bank account
example: PK36SCBL0000001123456702
minLength: 15
maxLength: 34
pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/PkrAccountInfo.yaml
Line: 30-31

Comment:
**Wrong IBAN example — German IBAN used for Pakistan**

Same copy-paste issue as `EgpAccountInfo.yaml`: the example `DE89370400440532013000` is a German IBAN. Pakistani IBANs start with `PK` and are 24 characters (e.g., `PK36SCBL0000001123456702`).

```suggestion
  iban:
    type: string
    description: The IBAN of the bank account
    example: PK36SCBL0000001123456702
    minLength: 15
    maxLength: 34
    pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
```

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

Fix in Claude Code

Comment on lines +19 to +20
type: string
description: The IBAN of the bank account
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 IBAN example is German, not Danish

The example DE89370400440532013000 is a 22-character German IBAN. Danish IBANs start with DK and are 18 characters. Consumers of this API doc may attempt to validate or test with a wrong-length IBAN.

Suggested change
type: string
description: The IBAN of the bank account
iban:
type: string
description: The IBAN of the bank account
example: DK5000400440116243
minLength: 15
maxLength: 34
pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/DkkAccountInfo.yaml
Line: 19-20

Comment:
**IBAN example is German, not Danish**

The example `DE89370400440532013000` is a 22-character German IBAN. Danish IBANs start with `DK` and are 18 characters. Consumers of this API doc may attempt to validate or test with a wrong-length IBAN.

```suggestion
  iban:
    type: string
    description: The IBAN of the bank account
    example: DK5000400440116243
    minLength: 15
    maxLength: 34
    pattern: ^[A-Z]{2}[0-9]{2}[A-Za-z0-9]{11,30}$
```

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

Fix in Claude Code

Comment on lines +30 to +31
swiftCode:
type: string
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 SWIFT example has wrong country code for Malaysia

MABORUMMYYY contains RU in the country-code position (characters 5–6) — that's Russia's ISO code, not Malaysia's (MY). Malaysian SWIFT codes should look like MBBEMYKL (Maybank). The pattern ^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$ won't catch this because it doesn't validate country codes.

Suggested change
swiftCode:
type: string
swiftCode:
type: string
description: The SWIFT/BIC code of the bank
example: MBBEMYKL
minLength: 8
maxLength: 11
pattern: ^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/MyrAccountInfo.yaml
Line: 30-31

Comment:
**SWIFT example has wrong country code for Malaysia**

`MABORUMMYYY` contains `RU` in the country-code position (characters 5–6) — that's Russia's ISO code, not Malaysia's (`MY`). Malaysian SWIFT codes should look like `MBBEMYKL` (Maybank). The pattern `^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$` won't catch this because it doesn't validate country codes.

```suggestion
  swiftCode:
    type: string
    description: The SWIFT/BIC code of the bank
    example: MBBEMYKL
    minLength: 8
    maxLength: 11
    pattern: ^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$
```

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

Fix in Claude Code

Comment on lines +6 to +8
- routingNumber
- bankName
- phoneNumber
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 phoneNumber required for all USD payment rails

phoneNumber is in the top-level required array, so it is mandatory even for pure domestic transfers (ACH, Wire, RTP, FedNow) where a phone number is not a banking requirement. If a USD bank account record in sparkcore can omit phoneNumber for those rails, API consumers receiving such a response will encounter a validation mismatch. Is this field only relevant for the new MOBILE_MONEY rail? If so, it should be optional (remove from required) with a note that it is required when paymentRails includes MOBILE_MONEY.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/common/UsdAccountInfo.yaml
Line: 6-8

Comment:
**`phoneNumber` required for all USD payment rails**

`phoneNumber` is in the top-level `required` array, so it is mandatory even for pure domestic transfers (ACH, Wire, RTP, FedNow) where a phone number is not a banking requirement. If a USD bank account record in sparkcore can omit `phoneNumber` for those rails, API consumers receiving such a response will encounter a validation mismatch. Is this field only relevant for the new `MOBILE_MONEY` rail? If so, it should be optional (remove from `required`) with a note that it is required when `paymentRails` includes `MOBILE_MONEY`.

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

Fix in Claude Code

@lightspark-copybara
Copy link
Copy Markdown
Contributor Author

Superseded by #353

@lightspark-copybara lightspark-copybara Bot deleted the auto/sync-grid-schemas-20260416-172831 branch April 20, 2026 18:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants