Skip to content

Comments

External Accounts Updates#202

Open
AaryamanBhute wants to merge 6 commits intomainfrom
changes-present
Open

External Accounts Updates#202
AaryamanBhute wants to merge 6 commits intomainfrom
changes-present

Conversation

@AaryamanBhute
Copy link
Contributor

No description provided.

@github-actions
Copy link

github-actions bot commented Feb 17, 2026

✱ Stainless preview builds

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

kotlin

feat: External Accounts Updates

openapi

feat(api): add 10 currency accounts, remove 7 legacy types, add originalQuoteId to quotes

python

feat(api): add BRL/DKK/GBP/HKD/IDR/INR/MXN/MYR/PHP/SGD/THB/USD/VND account types, quote field

typescript

feat(api): add BRL/DKK/GBP/HKD/IDR/INR/MXN/MYR/PHP/SGD/THB/USD/VND 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 "note" diagnostic, but this did not represent a regression.
generate ✅build ✅lint ✅test ✅

pip install https://pkg.stainless.com/s/grid-python/f294a7a1bde159133e28109a3b40eb7db7228edd/grid-0.0.1-py3-none-any.whl
New diagnostics (29 note)
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
grid-kotlin studio · code · diff

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

New diagnostics (111 note)
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
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/62eba583599c50be69fd9e926ba7ecab7001bd26/dist.tar.gz
New diagnostics (30 note)
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
grid-openapi studio · code · diff

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

New diagnostics (34 note)
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.
💡 Schema/RequiredPropertyNotDefined: This schema marks `accountType` as `required`, but it isn't defined in `properties`, so it will be ignored.

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-02-20 20:14:26 UTC

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Feb 17, 2026

Greptile Summary

This PR refactors the external account schemas from mechanism-based naming (US_ACCOUNT, PIX, CLABE, UPI) to currency-based naming (USD_ACCOUNT, BRL_ACCOUNT, MXN_ACCOUNT, etc.), adding support for 9 new currencies (BRL, DKK, HKD, IDR, INR, MXN, MYR, THB, VND) alongside existing GBP, PHP, SGD, and the renamed USD.

Key Changes:

  • Replaced UsAccountInfo with UsdAccountInfo - removed accountCategory (CHECKING/SAVINGS) field and validation patterns
  • Added beneficiary schemas for individual and business account holders across all currencies
  • Standardized all account schemas to include accountType, countries, and paymentRails fields
  • Updated discriminator mappings in PaymentInstructions and BaseExternalAccountInfo

Issues Found:

  • Consistency: Several new schemas have vague descriptions like "bank name of the bank" and "account number of the bank" (should reference beneficiary, not bank)
  • Validation: Most new currency schemas lack validation patterns, examples, and constraints that exist in well-defined schemas like GbpAccountInfo and SgdAccountInfo
  • Terminology: IdrAccountInfo uses sortCode (UK-specific) instead of bankCode for Indonesian banking
  • Breaking Change: UsdAccountInfo removes required accountCategory field from original UsAccountInfo without clear justification

Confidence Score: 3/5

  • This PR has some quality issues that should be addressed before merging
  • The refactoring from mechanism-based to currency-based naming is architecturally sound, but several new schemas lack validation patterns and have inconsistent/inaccurate descriptions. The removal of accountCategory from USD accounts may be a breaking change. While the changes won't cause runtime errors, the schema quality inconsistency and potential breaking change warrant review.
  • Pay close attention to UsdAccountInfo.yaml (potential breaking change), IdrAccountInfo.yaml (incorrect field naming), and currency schemas with missing validation: BrlAccountInfo, InrAccountInfo, HkdAccountInfo, ThbAccountInfo, VndAccountInfo, MyrAccountInfo, DkkAccountInfo

Important Files Changed

Filename Overview
openapi/components/schemas/common/UsdAccountInfo.yaml New USD schema replaces UsAccountInfo but lacks accountCategory, validation patterns, and examples that existed in original
openapi/components/schemas/common/BrlAccountInfo.yaml New BRL schema with PIX support, but field descriptions incorrectly attribute account holder data to "the bank"
openapi/components/schemas/common/IdrAccountInfo.yaml Uses sortCode field which is UK-specific terminology, should be bankCode for Indonesian banking
openapi/components/schemas/common/InrAccountInfo.yaml New INR schema with UPI/IMPS support, but VPA description incorrectly attributes it to "the bank"
openapi/components/schemas/common/HkdAccountInfo.yaml New HKD schema with redundant descriptions and missing validation patterns/examples
openapi/components/schemas/common/ThbAccountInfo.yaml New THB schema with same issues as HKD - redundant descriptions, no validation patterns
openapi/components/schemas/common/VndAccountInfo.yaml New VND schema with redundant descriptions and missing validation patterns
openapi/components/schemas/common/MyrAccountInfo.yaml New MYR schema with redundant descriptions and missing validation patterns
openapi/components/schemas/common/DkkAccountInfo.yaml New DKK schema with SEPA support but missing validation patterns for IBAN and SWIFT BIC

Entity Relationship Diagram

%%{init: {'theme': 'neutral'}}%%
erDiagram
    BaseExternalAccountInfo ||--o{ UsdExternalAccountInfo : extends
    BaseExternalAccountInfo ||--o{ BrlExternalAccountInfo : extends
    BaseExternalAccountInfo ||--o{ GbpExternalAccountInfo : extends
    BaseExternalAccountInfo ||--o{ InrExternalAccountInfo : extends
    
    UsdAccountInfo ||--|| UsdExternalAccountInfo : "account info"
    BrlAccountInfo ||--|| BrlExternalAccountInfo : "account info"
    GbpAccountInfo ||--|| GbpExternalAccountInfo : "account info"
    InrAccountInfo ||--|| InrExternalAccountInfo : "account info"
    
    UsdExternalAccountInfo ||--o{ UsdBeneficiary : "individual"
    UsdExternalAccountInfo ||--o{ BusinessBeneficiary : "business"
    BrlExternalAccountInfo ||--o{ BrlBeneficiary : "individual"
    BrlExternalAccountInfo ||--o{ BusinessBeneficiary : "business"
    
    UsdAccountInfo {
        string accountType "USD_ACCOUNT"
        array countries "US"
        array paymentRails "ACH,WIRE,RTP,FEDNOW"
        string accountNumber
        string routingNumber
    }
    
    BrlAccountInfo {
        string accountType "BRL_ACCOUNT"
        array countries "BR"
        array paymentRails "PIX"
        string pixKey
        string pixKeyType
        string taxId
    }
    
    InrAccountInfo {
        string accountType "INR_ACCOUNT"
        array countries "IN"
        array paymentRails "UPI,IMPS"
        string vpa
    }
    
    UsdBeneficiary {
        string beneficiaryType "INDIVIDUAL"
        string fullName
        string birthDate
        string nationality
    }
    
    BusinessBeneficiary {
        string beneficiaryType "BUSINESS"
        string legalName
        string registrationNumber
        string taxId
    }
Loading

Last reviewed commit: 1460f90

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

54 files reviewed, 7 comments

Edit Code Review Agent Settings | Greptile

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Feb 17, 2026

Additional Comments (2)

openapi/paths/customers/customers_external_accounts.yaml
Stale example using removed account type

This example still uses accountType: US_ACCOUNT with accountCategory: CHECKING and bankName, but this PR removes US_ACCOUNT from the ExternalAccountType enum and replaces it with USD_ACCOUNT. The new UsdAccountInfo schema does not include accountCategory or bankName fields.

This example will now fail validation against the updated schema. It needs to be updated to use the new USD_ACCOUNT type and only include the fields defined in UsdAccountInfo (accountNumber, routingNumber).

                accountType: USD_ACCOUNT
                accountNumber: "12345678901"
                routingNumber: "123456789"
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/paths/customers/customers_external_accounts.yaml
Line: 127:131

Comment:
**Stale example using removed account type**

This example still uses `accountType: US_ACCOUNT` with `accountCategory: CHECKING` and `bankName`, but this PR removes `US_ACCOUNT` from the `ExternalAccountType` enum and replaces it with `USD_ACCOUNT`. The new `UsdAccountInfo` schema does not include `accountCategory` or `bankName` fields.

This example will now fail validation against the updated schema. It needs to be updated to use the new `USD_ACCOUNT` type and only include the fields defined in `UsdAccountInfo` (`accountNumber`, `routingNumber`).

```suggestion
                accountType: USD_ACCOUNT
                accountNumber: "12345678901"
                routingNumber: "123456789"
```

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

openapi/paths/platform/platform_external_accounts.yaml
Stale example using removed account type

Same issue as in customers_external_accounts.yaml: this example uses accountType: US_ACCOUNT with accountCategory: CHECKING and bankName, but US_ACCOUNT is no longer a valid ExternalAccountType value in this PR, and the new UsdAccountInfo schema does not include accountCategory or bankName.

                accountType: USD_ACCOUNT
                accountNumber: "12345678901"
                routingNumber: "123456789"
Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/paths/platform/platform_external_accounts.yaml
Line: 89:93

Comment:
**Stale example using removed account type**

Same issue as in `customers_external_accounts.yaml`: this example uses `accountType: US_ACCOUNT` with `accountCategory: CHECKING` and `bankName`, but `US_ACCOUNT` is no longer a valid `ExternalAccountType` value in this PR, and the new `UsdAccountInfo` schema does not include `accountCategory` or `bankName`.

```suggestion
                accountType: USD_ACCOUNT
                accountNumber: "12345678901"
                routingNumber: "123456789"
```

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

AaryamanBhute and others added 5 commits February 20, 2026 10:42
Co-authored-by: Cursor <cursoragent@cursor.com>
Added beneficiary name verification fields to the External Account schema.

- Added a new `BeneficiaryVerificationStatus` enum with values: `MATCHED`, `PARTIAL_MATCH`, `NOT_MATCHED`, `UNSUPPORTED`, `CHECKED_BY_RECEIVING_FI`, and `PENDING`
- Added a new `VerifiedBeneficiaryData` object schema with a `fullName` property
- Extended the `ExternalAccount` schema to include:
  - `beneficiaryVerificationStatus` field to indicate the result of name verification
  - `beneficiaryVerifiedData` field to store verified account holder information

1. Create an external account with a beneficiary name
2. Verify that the API returns the appropriate verification status and verified data
3. Test each possible verification status to ensure proper handling

This change enables beneficiary name verification for external accounts, which helps prevent misdirected payments by confirming that the account holder name matches the expected beneficiary. This feature enhances security and reduces the risk of fraud or errors when sending payments to external accounts.
Co-authored-by: Cursor <cursoragent@cursor.com>
Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

82 files reviewed, 4 comments

Edit Code Review Agent Settings | Greptile

Comment on lines +26 to +30
type: string
description: The IBAN of the bank
swiftBic:
type: string
description: The SWIFT BIC of the bank
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing validation patterns and examples for IBAN and SWIFT BIC. Compare with GbpAccountInfo:27-36 which includes proper validation patterns, examples, and specific constraints (e.g., pattern: ^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$ for SWIFT code).

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

Comment:
Missing validation patterns and examples for IBAN and SWIFT BIC. Compare with `GbpAccountInfo:27-36` which includes proper validation patterns, examples, and specific constraints (e.g., `pattern: ^[A-Z]{4}[A-Z]{2}[A-Z0-9]{2}([A-Z0-9]{3})?$` for SWIFT code).

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

Comment on lines +26 to +30
type: string
description: The bank name of the bank
accountNumber:
type: string
description: The account number of the bank
Copy link
Contributor

Choose a reason for hiding this comment

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

Same redundant description issue as HkdAccountInfo - "bank name of the bank" and "account number of the bank". Also missing validation patterns and examples. Compare with NgnAccountInfo:26-34 which has precise descriptions, validation patterns, and examples.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

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

Comment:
Same redundant description issue as `HkdAccountInfo` - "bank name of the bank" and "account number of the bank". Also missing validation patterns and examples. Compare with `NgnAccountInfo:26-34` which has precise descriptions, validation patterns, and examples.

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

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

Comment on lines +26 to +30
type: string
description: The bank name of the bank
accountNumber:
type: string
description: The account number of the bank
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing validation patterns and examples. Consider adding specific constraints if Vietnamese bank account numbers have a standard format.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

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

Comment:
Missing validation patterns and examples. Consider adding specific constraints if Vietnamese bank account numbers have a standard format.

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

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

Comment on lines +26 to +30
type: string
description: The bank name of the bank
accountNumber:
type: string
description: The account number of the bank
Copy link
Contributor

Choose a reason for hiding this comment

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

Redundant descriptions and missing validation patterns. Same issues as ThbAccountInfo and VndAccountInfo.

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

Comment:
Redundant descriptions and missing validation patterns. Same issues as `ThbAccountInfo` and `VndAccountInfo`.

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

Update stale references to old payment-method-based schema names
(UsAccountExternalAccountInfo, PaymentClabeAccountInfo, etc.) and
remove BaseBeneficiary transform that no longer matches bundled output.

Co-authored-by: Cursor <cursoragent@cursor.com>
Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

83 files reviewed, 5 comments

Edit Code Review Agent Settings | Greptile

Comment on lines +28 to +33
accountNumber:
type: string
description: The account number of the bank
routingNumber:
type: string
description: The routing number of the bank
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing validation patterns and examples. The original UsAccountInfo included:

  • routingNumber with minLength: 9, maxLength: 9, pattern: ^[0-9]{9}$, and example
  • accountNumber with example
  • More precise descriptions

Also, the required accountCategory field (CHECKING/SAVINGS) was removed - confirm this isn't a breaking change for existing integrations.

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

Comment:
Missing validation patterns and examples. The original `UsAccountInfo` included:
- `routingNumber` with `minLength: 9`, `maxLength: 9`, `pattern: ^[0-9]{9}$`, and example
- `accountNumber` with example
- More precise descriptions

Also, the required `accountCategory` field (CHECKING/SAVINGS) was removed - confirm this isn't a breaking change for existing integrations.

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

Comment on lines +25 to +27
sortCode:
type: string
description: The sort code of the bank
Copy link
Contributor

Choose a reason for hiding this comment

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

sortCode is UK-specific banking terminology. Indonesian banks use "bank code" (kode bank) for routing. Rename to bankCode for accuracy.

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

Comment:
`sortCode` is UK-specific banking terminology. Indonesian banks use "bank code" (kode bank) for routing. Rename to `bankCode` for accuracy.

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

Comment on lines +26 to +34
pixKey:
type: string
description: The PIX key of the bank
pixKeyType:
type: string
description: The type of PIX key of the bank
taxId:
type: string
description: The tax ID of the bank account
Copy link
Contributor

Choose a reason for hiding this comment

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

Descriptions incorrectly attribute account holder data to "the bank". PIX keys and tax IDs belong to the beneficiary/account holder, not the bank. Compare with GbpAccountInfo:27 which uses precise language like "UK bank sort code".

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

Comment:
Descriptions incorrectly attribute account holder data to "the bank". PIX keys and tax IDs belong to the beneficiary/account holder, not the bank. Compare with `GbpAccountInfo:27` which uses precise language like "UK bank sort code".

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

Comment on lines +25 to +30
bankName:
type: string
description: The bank name of the bank
accountNumber:
type: string
description: The account number of the bank
Copy link
Contributor

Choose a reason for hiding this comment

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

Redundant descriptions: "bank name of the bank" and "account number of the bank". Use clearer phrasing like SgdAccountInfo:30 ("Name of the beneficiary's bank") and add validation patterns/examples.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

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

Comment:
Redundant descriptions: "bank name of the bank" and "account number of the bank". Use clearer phrasing like `SgdAccountInfo:30` ("Name of the beneficiary's bank") and add validation patterns/examples.

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

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

Comment on lines +26 to +30
type: string
description: The IBAN of the bank
swiftBic:
type: string
description: The SWIFT BIC of the bank
Copy link
Contributor

Choose a reason for hiding this comment

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

Missing validation patterns for IBAN and SWIFT BIC. Reference GbpAccountInfo:29 and SgdAccountInfo:33-38 which include proper patterns, length constraints, and examples.

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

Comment:
Missing validation patterns for IBAN and SWIFT BIC. Reference `GbpAccountInfo:29` and `SgdAccountInfo:33-38` which include proper patterns, length constraints, and examples.

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

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.

2 participants