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 two new external account schemas from sparkcore VASP adapter field definitions: InrUpiAccountInfo.yaml for INR UPI accounts and MxnSpeiAccountInfo.yaml for Mexican SPEI accounts.

Key Issues:

• Both schemas introduce new account types (INR_UPI_ACCOUNT, MXN_SPEI_ACCOUNT) but are not registered in ExternalAccountInfoOneOf.yaml or ExternalAccountType.yaml, making them unusable in the API
• Field naming inconsistencies: these schemas use standalone fullName/name fields instead of the established beneficiary object pattern used in existing account types
• MxnSpeiAccountInfo uses clabe field without validation constraints (missing minLength, maxLength, pattern), while existing ClabeAccountInfo.yaml has proper 18-digit validation
• Schema structure differs from existing patterns - standalone objects rather than allOf compositions with BaseExternalAccountInfo

Questions:

• Are these schemas intended for internal VASP operations only, or should they be integrated into the public API?
• Should these follow the existing architecture patterns, or is this a new parallel structure?

Confidence Score: 2/5

• This PR introduces schemas that are not integrated into the API and have inconsistencies with existing patterns
• Score reflects critical integration gaps - the new account types are not registered in discriminator mappings or enum definitions, making them non-functional. Additionally, field naming and validation patterns deviate from established conventions without clear justification.
• Both InrUpiAccountInfo.yaml and MxnSpeiAccountInfo.yaml require attention for integration and consistency issues

Important Files Changed

Filename	Overview
openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml	New INR UPI account schema added, but not integrated into ExternalAccountInfoOneOf or ExternalAccountType enum
openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml	New MXN SPEI account schema added with inconsistent field names compared to existing patterns

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant Sparkcore as Sparkcore (VASP Adapter)
    participant AutoSync as Auto-sync Process
    participant GridAPI as Grid API Schemas
    participant OpenAPI as OpenAPI Specification
    
    Note over Sparkcore: VASP adapter field<br/>definitions updated
    Sparkcore->>AutoSync: Trigger schema sync
    AutoSync->>GridAPI: Generate InrUpiAccountInfo.yaml
    AutoSync->>GridAPI: Generate MxnSpeiAccountInfo.yaml
    Note over GridAPI: New schemas added to<br/>external_accounts/
    GridAPI->>OpenAPI: Schemas available for use
    Note over OpenAPI: ⚠️ Not registered in<br/>ExternalAccountInfoOneOf<br/>or ExternalAccountType
    Dev->>GridAPI: Review PR #143
    Note over Dev: Verify integration<br/>requirements

Loading

[greptile-apps]

_{2 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

This schema introduces INR_UPI_ACCOUNT as a new account type but it's not registered in:

1. ExternalAccountInfoOneOf.yaml (discriminator oneOf list and mapping)
2. ExternalAccountType.yaml (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

Prompt To Fix With AI

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

Comment:
This schema introduces `INR_UPI_ACCOUNT` as a new account type but it's not registered in:
1. `ExternalAccountInfoOneOf.yaml` (discriminator oneOf list and mapping)
2. `ExternalAccountType.yaml` (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

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

[greptile-apps]

Field fullName is inconsistent with existing patterns. The existing UpiAccountExternalAccountInfo.yaml uses a beneficiary object with IndividualBeneficiary or BusinessBeneficiary types. This standalone fullName field doesn't align with the established beneficiary pattern used across other account types.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml
Line: 14:17

Comment:
Field `fullName` is inconsistent with existing patterns. The existing `UpiAccountExternalAccountInfo.yaml` uses a `beneficiary` object with `IndividualBeneficiary` or `BusinessBeneficiary` types. This standalone `fullName` field doesn't align with the established beneficiary pattern used across other account types.

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

[greptile-apps]

This schema introduces MXN_SPEI_ACCOUNT as a new account type but it's not registered in:

1. ExternalAccountInfoOneOf.yaml (discriminator oneOf list and mapping)
2. ExternalAccountType.yaml (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

Prompt To Fix With AI

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

Comment:
This schema introduces `MXN_SPEI_ACCOUNT` as a new account type but it's not registered in:
1. `ExternalAccountInfoOneOf.yaml` (discriminator oneOf list and mapping)
2. `ExternalAccountType.yaml` (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

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

[greptile-apps]

Field clabe differs from existing pattern in ClabeAccountInfo.yaml which uses clabeNumber with validation (18 digits, pattern ^[0-9]{18}$). This schema lacks the validation constraints present in the existing implementation.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 14:17

Comment:
Field `clabe` differs from existing pattern in `ClabeAccountInfo.yaml` which uses `clabeNumber` with validation (18 digits, pattern `^[0-9]{18}$`). This schema lacks the validation constraints present in the existing implementation.

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

[greptile-apps]

Field name is inconsistent with existing patterns. The existing ClabeAccountExternalAccountInfo.yaml uses a beneficiary object structure. This standalone name field doesn't align with the established beneficiary pattern used across other account types.

Prompt To Fix With AI

This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 18:21

Comment:
Field `name` is inconsistent with existing patterns. The existing `ClabeAccountExternalAccountInfo.yaml` uses a `beneficiary` object structure. This standalone `name` field doesn't align with the established beneficiary pattern used across other account types.

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