Encryption in transit and at rest
Brokerage data moves over encrypted channels and is encrypted at rest. Sessions are authenticated before account-scoped reads or trading.
Security
Protect the connection without pretending every broker is OAuth
Encryption, authenticated sessions, and the authorization flow each institution actually supports — including the few that only offer username-and-password APIs.
What Finatic holds
- Encrypted session material for connected institutions.
- Normalized account, position, order, and balance data needed to serve your product.
- Username and password for the small set of brokers that only expose that API — encrypted at rest, used only to establish and maintain the session.
What your app never has to collect
- Per-broker OAuth, token, or hosted-authorization flows. Connect runs those.
- A custom login form for every institution in the catalog.
- Raw broker secrets in your application code or frontend.
Institution-supported authorization
Users complete the flow each brokerage actually supports — OAuth, API keys, tokens, Flex Tokens, or a broker-hosted session — inside your branded Connect portal.
Your product does not collect broker secrets
Connect is the place users authenticate. Your application receives Finatic session context, not a pile of per-broker login forms to maintain.
Enterprise controls by engagement
Production volume, support, and additional commercial or security requirements are designed with your organization.
Credentials, stated accurately
Most institutions connect through OAuth, API keys, tokens, or a broker-hosted authorization flow. Finatic does not ask your product to collect those secrets.
A small number of brokers only expose username-and-password APIs. For those connections, credentials are encrypted at rest and used only to establish and maintain the session. That exception is documented on the institution’s integration page.