Documentação

English

Português
Español

English

Português
Español

Appearance

Digital Banking Creation Failures ​

Access prerequisites

  • Permission (module): digitalAccountErrors
  • License/Feature: DIGITAL_BANKING enabled on the tenant license
  • Menu container: GENERAL → Audit group

What it is / when to use ​

The Digital Banking Creation Failures screen (/digital-account-errors) lists digital account opening attempts (digital banking via BaaS) that remained pending or failed at the provider. Each record stores the userId, the provider, the error code, the opening payload sent, and the error payload returned.

Use this screen to diagnose why a user's account was not opened at the digital bank, reprocess/forward the correction, and mark the case as resolved. It is the audit layer that survives a provider crash: the opening payload is persisted regardless of the response.

Prerequisites ​

  • Permission: digitalAccountErrors module. Permission is dual — CPM enum in the backend + dynamic module in the DB.
  • License/Feature: DIGITAL_BANKING enabled (Vault). If disabled, the item does not appear in the menu at all.
  • Dependencies on other screens: the record comes from the account opening audit chain (payload in digital_account_creation.body in the BSM + banking-audit middleware in the BLS). The checkOnboarding in the BaaS-Gateway always responds from the BLS — accounts that exist only at the provider, with no record in the BLS, may appear as inconsistencies.

Step by step ​

  1. Access the menu GENERAL → Audit → Digital Banking Creation Failures.
  2. The table loads the paginated records (10/25/50/100 per page).
  3. (Optional) Filter by User ID and/or Status (PENDING, SUCCESS, ERROR) and click Apply.
  4. Click a row (or View details) to open the modal with the complete payloads.
  5. If the record is in ERROR status, use Mark as resolved after handling the case.

Filters and columns ​

Filter / ColumnWhat it showsData source
User ID (filter)Filters the list by the target useruserId parameter sent to the backend
Status (filter)PENDING, SUCCESS or ERRORstatus parameter
User ID (column)User whose opening faileduserId
ProviderDestination BaaS providerprovider
Error codeCode returned by the provider/integrationerrorCode
Created atMoment of the attemptcreatedAt
ActionsOpens the details—

Fields (details modal) ​

FieldWhat it isSource
StatusCurrent state of the recordstatus
Body (opening payload)JSON sent to the provider when creating the accountbody
Error payloadReturned error JSONerrorPayload

Actions and modals ​

  • Apply / Clear filters: reruns the query (resetting pagination) or clears the filters.
  • Refresh: reloads the list.
  • View details: opens the DigitalAccountErrorDetailsModal with the formatted payloads (JSON).
  • Mark as resolved: available only when status === 'ERROR'. Asks for confirmation (confirm) and calls the backend to settle the record. Upon completion, closes the modal and reloads the list.

Business rules / caveats ​

Caution

  • "Mark as resolved" is an audit trail action: it records that the case was handled. It does not recreate the account on its own — the effective correction (new onboarding, data adjustment, backfill in the BLS) must be done through the appropriate flow.
  • For legacy accounts that exist at the provider but not in the BLS, checkOnboarding returns 404 — these cases require a backfill in the BLS, not just "mark as resolved".
  • The opening payload contains PII (documents, holder data). Handle it in accordance with LGPD.
  • Step-up: sensitive digital banking actions may require re-authentication (password+MFA, header X-Step-Up-Token) depending on the tenant configuration.