# Open Finance vs Direct: field differences

Pluggy returns the same objects — `Transaction`, `Account`, `Identity` — whichever way an item
was connected. **The objects are the same shape, but not every field is filled from both
sources.** A field that is always present for one customer can be permanently `null` for another,
purely because of the connection type.

This page lists the fields that exist on **one side only**, so you can tell "this institution
does not send it" apart from "this never arrives through this kind of connection".

<Callout variant="info" title="Missing a field that is not listed here?">
Then it is a per-institution coverage question, not a connection-type one. The coverage pages break it down per connector: [Credit Cards](/docs/connections/credit-cards-coverage), [Accounts](/docs/connections/accounts-coverage), [Payment Data](/docs/connections/paymentdata-coverage), [Identity](/docs/connections/identity-coverage).
</Callout>

## Why they differ

**Open Finance (regulated)** connections read the institution's regulated APIs. The schema is
fixed by the Open Finance Brasil specification, so every institution returns the same shape and
Pluggy maps it once. If the specification has no field for something, no institution can send
it — the gap is regulatory, not technical, and no amount of per-institution work closes it.

**Direct** connections read the institution's own channels. There is no common schema, so what
arrives depends on what each institution exposes. This is why direct coverage is published per
connector, while Open Finance coverage is essentially uniform.

The practical consequence: Open Finance gives you **breadth and consistency**, direct connectors
sometimes give you **fields the regulation never defined**.

## Open Finance only

| Field | Object | Notes |
| :-- | :-- | :-- |
| `providerId` | `Transaction` | The institution's own transaction id. The only stable provider-side identifier we expose. Direct connectors have no guaranteed equivalent — reconcile on `date` + `amount` + `description` instead. |
| `creditCardMetadata.billId` | `Transaction` | Links the transaction to the bill it was charged to. |
| `brandAdditionalInfo` | `Account` | Free text describing the brand when `brand` is `OTHER`. |
| `investorProfile` | `Identity` | Investor profile classification (Conservative, Moderate, Aggressive). |
| `qualifications` | `Identity` | Income, patrimony and occupation data. |
| `financialRelationships` | `Identity` | The customer's products and relationship start date with the institution. |
| `openFinancePermissionsGranted` | `Consent` | The permissions the user actually consented to. Has no meaning for a direct connection. |

The [real-time balance endpoint](/docs/products/real-time-balance) is also Open Finance only —
calling it on a non-Open-Finance account returns an error.

## Direct only

| Field | Object | Notes |
| :-- | :-- | :-- |
| `creditCardMetadata.totalAmount` | `Transaction` | The total value of an instalment purchase (the sum of every instalment). The Open Finance credit-card schema has no equivalent: it reports each instalment, never the purchase total. Available on some direct connectors — see [Credit Cards Coverage](/docs/connections/credit-cards-coverage). |
| `balance` on each transaction | `Transaction` | Running balance after the transaction. Supported by Itaú PJ, Sicredi PF & PJ and Bradesco PJ. |

<Callout variant="warning" title="totalAmount appears twice, and the two are unrelated">
- `creditCardMetadata.totalAmount`, on a **transaction** — the purchase total of an instalment plan. **Direct only.**
- `totalAmount`, on a **bill** — the amount of the whole bill. **Available on Open Finance**, mapped from `billTotalAmount`.

Seeing a populated `totalAmount` on a bill in an Open Finance connection does not mean the transaction-level field will be populated too.
</Callout>

## Fields people expect to be exclusive, but are not

`paymentData` — the payer/payee detail on a transfer — is **populated by both**. Open Finance
maps it from the regulated transaction parties, and direct connectors extract it where the
institution exposes it. What varies is *how completely* it is filled, per institution, which is
what [Payment Data Coverage](/docs/connections/paymentdata-coverage) tracks.

The same holds for `merchant`, `category` and `operationType`: both sides can populate them, with
per-institution differences in how much detail arrives.

## Scope and freshness

This page covers **Transactions, Accounts, Identity and Consents**, which is where the question
comes up in practice. Investments, Loans and Brokerage Notes are not broken down here yet; for
those, treat the per-connector coverage pages as the source of truth.

The list is derived from the connector mappers, not from sampling production data — a field
listed as available can still be `null` for a given institution or a given transaction. Presence
here means *this connection type can return it*, not *it is always there*.

Last reviewed: **2026-09-07**, against the Open Finance Brasil Credit Card API v2.4.0 mapping.