# Open Finance vs Direct: diferenças de campo

Pluggy retorna os mesmos objetos — `Transaction`, `Account`, `Identity` — independentemente de como um item foi conectado. **Os objetos têm a mesma estrutura, mas nem todos os campos estão preenchidos a partir de ambas as fontes.** Um campo que está sempre presente para um cliente pode estar permanentemente `null` para outro, puramente por causa do tipo de conexão.

Esta página lista os campos que existem **apenas de um lado**, para que você possa distinguir "esta instituição não envia" de "isso nunca chega através deste tipo de conexão".

<Callout variant="info" title="Faltando um campo que não está listado aqui?">
Então é uma questão de cobertura por instituição, não de tipo de conexão. As páginas de cobertura detalham por conector: [Credit Cards](/docs/connections/credit-cards-coverage), [Accounts](/docs/connections/accounts-coverage), [Payment Data](/docs/connections/paymentdata-coverage), [Identity](/docs/connections/identity-coverage).
</Callout>

## Por que eles diferem

**Conexões de Open Finance (regulamentadas)** leem as APIs regulamentadas da instituição. O esquema é fixado pela especificação do Open Finance Brasil, então cada instituição retorna a mesma estrutura e o Pluggy a mapeia uma vez. Se a especificação não tem um campo para algo, nenhuma instituição pode enviá-lo — a lacuna é regulatória, não técnica, e nenhum trabalho por instituição a fecha.

**Conexões Diretas** leem os próprios canais da instituição. Não há um esquema comum, então o que chega depende do que cada instituição expõe. É por isso que a cobertura direta é publicada por conector, enquanto a cobertura de Open Finance é essencialmente uniforme.

A consequência prática: Open Finance oferece **amplitude e consistência**, enquanto conectores diretos às vezes oferecem **campos que a regulamentação nunca definiu**.

## Somente Open Finance

| Campo | Objeto | Notas |
| :-- | :-- | :-- |
| `providerId` | `Transaction` | O id da transação da própria instituição. O único identificador estável do lado do provedor que expomos. Conectores diretos não têm equivalente garantido — reconcilie por `date` + `amount` + `description` em vez disso. |
| `creditCardMetadata.billId` | `Transaction` | Liga a transação à fatura à qual foi cobrada. |
| `brandAdditionalInfo` | `Account` | Texto livre descrevendo a marca quando `brand` é `OTHER`. |
| `investorProfile` | `Identity` | Classificação do perfil do investidor (Conservador, Moderado, Agressivo). |
| `qualifications` | `Identity` | Dados de renda, patrimônio e ocupação. |
| `financialRelationships` | `Identity` | Os produtos do cliente e a data de início do relacionamento com a instituição. |
| `openFinancePermissionsGranted` | `Consent` | As permissões que o usuário realmente consentiu. Não tem significado para uma conexão direta. |

O [endpoint de saldo em tempo real](/docs/products/real-time-balance) também é somente Open Finance — chamá-lo em uma conta não-Open-Finance retorna um erro.

## Somente Direto

| Campo | Objeto | Notas |
| :-- | :-- | :-- |
| `creditCardMetadata.totalAmount` | `Transaction` | O valor total de uma compra parcelada (a soma de cada parcela). O esquema de cartão de crédito do Open Finance não tem equivalente: ele relata cada parcela, nunca o total da compra. Disponível em alguns conectores diretos — veja [Credit Cards Coverage](/docs/connections/credit-cards-coverage). |
| `balance` em cada transação | `Transaction` | Saldo corrente após a transação. Suportado por Itaú PJ, Sicredi PF & PJ e Bradesco PJ. |

<Callout variant="warning" title="totalAmount aparece duas vezes, e as duas estão não relacionadas">
- `creditCardMetadata.totalAmount`, em uma **transação** — o total da compra de um plano de parcelamento. **Somente Direto.**
- `totalAmount`, em uma **fatura** — o valor da fatura inteira. **Disponível no Open Finance**, mapeado de `billTotalAmount`.

Ver um `totalAmount` preenchido em uma fatura em uma conexão Open Finance não significa que o campo de nível de transação também estará preenchido.
</Callout>

## Campos que as pessoas esperam que sejam exclusivos, mas não são

`paymentData` — os detalhes do pagador/recebedor em uma transferência — é **preenchido por ambos**. Open Finance o mapeia a partir das partes da transação regulamentada, e conectores diretos o extraem onde a instituição o expõe. O que varia é *quão completamente* ele é preenchido, por instituição, que é o que [Payment Data Coverage](/docs/connections/paymentdata-coverage) rastreia.

O mesmo se aplica a `merchant`, `category` e `operationType`: ambos os lados podem preenchê-los, com diferenças por instituição em quão detalhado chega.

## Escopo e atualidade

Esta página cobre **Transações, Contas, Identidade e Consentimentos**, que é onde a questão surge na prática. Investimentos, Empréstimos e Notas de Corretagem ainda não estão detalhados aqui; para esses, trate as páginas de cobertura por conector como a fonte da verdade.

A lista é derivada dos mapeadores de conectores, não de amostragem de dados de produção — um campo listado como disponível ainda pode ser `null` para uma determinada instituição ou uma determinada transação. A presença aqui significa *este tipo de conexão pode retorná-lo*, não *ele está sempre lá*.

Última revisão: **2026-09-07**, em relação ao mapeamento da API de Cartão de Crédito do Open Finance Brasil v2.4.0.