chore: Update external account schemas from webdev

[lightspark-copybara]

Auto-synced external account schemas from webdev.

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

Please review the changes before merging.

[greptile-apps]

Greptile Overview

Greptile Summary

Auto-synced schemas add support for INR (Indian Rupee) and MXN (Mexican Peso) external accounts with their respective payment rails (UPI and SPEI). However, the generated schemas deviate from the established architectural pattern used by all other external account types in this codebase.

Key Issues

• Architecture inconsistency: Both new schemas (InrAccountInfo.yaml and MxnAccountInfo.yaml) define their structures inline instead of using the allOf composition pattern that all existing account types follow (e.g., UpiAccountExternalAccountInfo.yaml, ClabeAccountExternalAccountInfo.yaml)
• Missing enum entries: INR_ACCOUNT and MXN_ACCOUNT are not added to the ExternalAccountType.yaml enum or BaseExternalAccountInfo.yaml discriminator mapping
• Beneficiary schema inconsistency: The new schemas define beneficiary properties inline rather than referencing BeneficiaryOneOf.yaml, which provides proper discriminated union typing for INDIVIDUAL vs BUSINESS beneficiaries
• Field duplication: VPA and CLABE fields are redefined instead of referencing existing common schemas (common/UpiAccountInfo.yaml and common/ClabeAccountInfo.yaml)

Expected Pattern

The schemas should follow this structure:

allOf:
  - $ref: ./BaseExternalAccountInfo.yaml
  - $ref: ../common/[Currency]AccountInfo.yaml
  - type: object
    required:
      - beneficiary
    properties:
      beneficiary:
        $ref: ./BeneficiaryOneOf.yaml

These inconsistencies will likely cause schema validation issues and break the discriminator-based polymorphism used throughout the API.

Confidence Score: 2/5

• This PR introduces structural inconsistencies that will likely break schema validation
• The new schemas deviate significantly from the established architectural pattern, missing critical enum entries and using inline definitions instead of the allOf composition pattern. These issues will break discriminator-based polymorphism and may cause validation failures when the OpenAPI schema is bundled.
• InrAccountInfo.yaml and MxnAccountInfo.yaml need to be restructured to follow the existing pattern, and ExternalAccountType.yaml and BaseExternalAccountInfo.yaml need updates to include the new account types

Important Files Changed

Filename	Overview
openapi/components/schemas/external_accounts/InrAccountInfo.yaml	New INR account schema added with UPI payment rail, but doesn't follow existing architecture pattern (should use allOf with common schemas) and missing from ExternalAccountType enum
openapi/components/schemas/external_accounts/MxnAccountInfo.yaml	New MXN account schema added with SPEI payment rail, but doesn't follow existing architecture pattern (should use allOf with common schemas) and missing from ExternalAccountType enum
openapi/components/schemas/external_accounts/ExternalAccountInfoOneOf.yaml	Added INR and MXN account types to oneOf union and discriminator mapping, indentation formatting changed from 2 spaces to consistent YAML style

Sequence Diagram

sequenceDiagram
    participant Dev as Webdev Repo
    participant Bot as Copybara Bot
    participant Schemas as External Account Schemas
    participant OneOf as ExternalAccountInfoOneOf
    participant Enum as ExternalAccountType

    Dev->>Bot: Generate INR & MXN schemas from VASP adapter
    Bot->>Schemas: Create InrAccountInfo.yaml
    Bot->>Schemas: Create MxnAccountInfo.yaml
    Bot->>OneOf: Add INR & MXN to oneOf union
    Bot->>OneOf: Add discriminator mappings
    Note over Enum: ⚠️ Missing: INR_ACCOUNT & MXN_ACCOUNT not added to enum
    Note over Schemas: ⚠️ Issue: Schemas don't use allOf pattern
    Note over Schemas: ⚠️ Issue: Inline beneficiary instead of BeneficiaryOneOf ref

Loading

[greptile-apps]

_{3 files reviewed, 4 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Schema doesn't follow the existing architecture pattern used by other account types. Compare with UpiAccountExternalAccountInfo.yaml (lines 1-9) which uses allOf to compose BaseExternalAccountInfo.yaml, common/UpiAccountInfo.yaml, and adds beneficiary requirements. This schema duplicates the VPA field definition instead of referencing the common schema.

Also missing INR_ACCOUNT from ExternalAccountType.yaml enum and BaseExternalAccountInfo.yaml discriminator mapping.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/InrAccountInfo.yaml
Line: 1:59

Comment:
Schema doesn't follow the existing architecture pattern used by other account types. Compare with `UpiAccountExternalAccountInfo.yaml` (lines 1-9) which uses `allOf` to compose `BaseExternalAccountInfo.yaml`, `common/UpiAccountInfo.yaml`, and adds beneficiary requirements. This schema duplicates the VPA field definition instead of referencing the common schema.

Also missing `INR_ACCOUNT` from `ExternalAccountType.yaml` enum and `BaseExternalAccountInfo.yaml` discriminator mapping.

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

[greptile-apps]

Schema doesn't follow the existing architecture pattern used by other account types. Compare with ClabeAccountExternalAccountInfo.yaml (lines 1-9) which uses allOf to compose BaseExternalAccountInfo.yaml, common/ClabeAccountInfo.yaml, and adds beneficiary requirements. This schema duplicates the CLABE field definition instead of referencing the common schema.

Also missing MXN_ACCOUNT from ExternalAccountType.yaml enum and BaseExternalAccountInfo.yaml discriminator mapping.

_{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/external_accounts/MxnAccountInfo.yaml
Line: 1:61

Comment:
Schema doesn't follow the existing architecture pattern used by other account types. Compare with `ClabeAccountExternalAccountInfo.yaml` (lines 1-9) which uses `allOf` to compose `BaseExternalAccountInfo.yaml`, `common/ClabeAccountInfo.yaml`, and adds beneficiary requirements. This schema duplicates the CLABE field definition instead of referencing the common schema.

Also missing `MXN_ACCOUNT` from `ExternalAccountType.yaml` enum and `BaseExternalAccountInfo.yaml` discriminator mapping.

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

[greptile-apps]

Beneficiary structure is inconsistent with existing pattern. Other external account types (e.g., ClabeAccountExternalAccountInfo.yaml:8, UpiAccountExternalAccountInfo.yaml:8) reference BeneficiaryOneOf.yaml which provides proper discriminator-based typing between INDIVIDUAL and BUSINESS beneficiaries with beneficiaryType property.

_{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/external_accounts/InrAccountInfo.yaml
Line: 29:59

Comment:
Beneficiary structure is inconsistent with existing pattern. Other external account types (e.g., `ClabeAccountExternalAccountInfo.yaml:8`, `UpiAccountExternalAccountInfo.yaml:8`) reference `BeneficiaryOneOf.yaml` which provides proper discriminator-based typing between `INDIVIDUAL` and `BUSINESS` beneficiaries with `beneficiaryType` property.

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

[greptile-apps]

Beneficiary structure is inconsistent with existing pattern. Other external account types (e.g., ClabeAccountExternalAccountInfo.yaml:8, UpiAccountExternalAccountInfo.yaml:8) reference BeneficiaryOneOf.yaml which provides proper discriminator-based typing between INDIVIDUAL and BUSINESS beneficiaries with beneficiaryType property.

_{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/external_accounts/MxnAccountInfo.yaml
Line: 33:61

Comment:
Beneficiary structure is inconsistent with existing pattern. Other external account types (e.g., `ClabeAccountExternalAccountInfo.yaml:8`, `UpiAccountExternalAccountInfo.yaml:8`) reference `BeneficiaryOneOf.yaml` which provides proper discriminator-based typing between `INDIVIDUAL` and `BUSINESS` beneficiaries with `beneficiaryType` property.

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