Freedom24's authenticated portal, mapped for one integration

Behind a Freedom24 login sits a CIF-licensed broker — Freedom Finance Europe Ltd, holder of CySEC licence CIF 275/15 per Freedom24's own regulatory disclosure — that records every order, every fill, and every cash movement across roughly fifteen stock exchanges in the US, Europe and Asia. That is the source. The integration question is how to get it out of the member portal cleanly, in a normalized shape, on behalf of a consenting account holder, without breaking when the portal changes shape next quarter.

The bottom line: this is a rich authenticated-portal integration, not an open-data fetch. The data is high-quality and well structured because a regulated broker has to keep it that way for its own books, but it lives behind a personal session and tax-grade reports. Our recommendation is to anchor the pull on the brokerage-report family (broker report, custody report, tax report) for ledger-grade truth, and use the live portfolio surface for everything that has to be fresh — quotes, open orders, working positions.

What sits behind the login

The Freedom24 member area exposes a small but engineering-friendly set of data domains. The names below match how the app itself labels them where possible.

Routes to the data

Three routes apply to this account; one of them is the spine and the others are situational.

1. Authorized session integration against the member portal

This is the route we run by default. With the account holder's written consent, we drive an authenticated session through the same auth flow a Freedom24 user uses (login, second factor where present, session refresh) and pull the structured surfaces — portfolio JSON, brokerage report generation, custody, and the tax report. It works for any Freedom24 account in good standing and gives us the same fidelity the user sees. Effort is moderate on the first build and small per maintenance cycle. Durability is good as long as a conformance check is in place.

2. Scheduled broker-report pull

A narrower lane for when the brief is only "give us the broker report on a schedule". We hold the authorization, request the report on the cadence you set (daily, weekly, end-of-month), and drop the signed file plus a parsed JSON view into your store. Low overhead per cycle and well suited to back-office and tax-prep flows that do not need live portfolio data.

3. Protocol analysis of the mobile traffic

If the user-side surface is the only one in scope (for example, you want what the Android app shows on the watchlist, not what the broker books show), we analyze the mobile app's authorized traffic under the client's instruction and rebuild the calls in a documented spec. Slower than route 1 and used when the brief is specifically about the mobile experience, not the broker ledger.

For a first engagement we would lead with route 1 and add route 2 for the report cadence; route 3 is brought in only if the mobile-only surface matters.

A look at the pull

Illustrative sketch — endpoint paths, field names and auth steps are confirmed during the build against the live member area for the consenting account.

# Python — illustrative; field names confirmed at build time.
from f24_session import F24Session, F24Error

with F24Session(
    user="member@example.eu",
    secret_provider=vault.get("f24/totp"),  # 2FA seed handled outside code
    consent_ref="C-2026-05-30-001",         # signed customer authorization
) as s:
    portfolio = s.get_portfolio(
        accounts=["live", "demo"],
        currency_base="EUR",
    )

    trades = s.iter_trades(
        from_="2026-01-01",
        to_="2026-05-30",
        venues=None,        # all venues the account is enabled for
        include_fx=True,
    )

    report = s.request_broker_report(
        period=("2026-01-01", "2026-05-30"),
        kind="broker",      # broker | custody | tax
        delivery="link",
    )

    normalized = {
        "positions": [normalize_position(p, base="EUR") for p in portfolio.positions],
        "trades": [normalize_trade(t, base="EUR") for t in trades],
        "documents": [{"kind": report.kind, "url": report.signed_url, "ttl": report.ttl}],
    }

# Error contract is part of the deliverable.
# F24Error subclasses: AuthChallenge, ConsentExpired, RateLimited,
# ReportPending, PortalSchemaDrift.

The two things to notice. First, every call carries a consent_ref — a signed authorization the customer issued, logged on our side and revocable at any moment. Second, PortalSchemaDrift is a first-class exception, not a runtime crash. The integration is built to notice when Freedom24 has moved a field and surface that as a maintainable signal rather than as a 500 to your downstream system.

What lands on your stack

The handover is the same whether you take source-code delivery or call the hosted version. What changes is who runs it.

• An OpenAPI 3.1 specification for the normalized Freedom24 surface (portfolio, trades, cash, documents, account profile).
• A short protocol and auth-flow report — login handshake, second-factor handling, token lifetime, refresh path, and where consent records sit. Specific to this app, written so a security team can review it.
• Runnable source in Python and Node.js for the core endpoints, with the error contract above wired in.
• An automated test pack: fixture-based unit tests for the normalizer, and a small live conformance check that exercises a sandbox or consenting demo account against the real portal.
• Interface documentation — one document a downstream engineer can read in twenty minutes to know what each field means, why it is shaped that way, and what changes when a venue or currency is added.
• A short compliance and data-retention note: what we log, what the customer logs, how long consent is good for, how revocation propagates.

Consent and the CySEC frame

Freedom Finance Europe Ltd is supervised by CySEC under the MiFID II conduct regime, with GDPR (and Cyprus Law 125(I)/2018 in the firm's home jurisdiction) on top. None of that prescribes an open-banking-style customer data right for brokerage data — the European AIS/PSD2 framework is about payment accounts, not investment accounts. What it does prescribe is the discipline around how a client's data is held and shared.

The dependable basis for the integration, therefore, is the account holder's own written authorization. We work to a one-page consent: the data domains in scope (positions, trades, documents, profile), the period covered, the third party receiving the data, the means of revocation. The consent is timestamped, stored, and re-asked at renewal. If the client is a corporate account or a wealth manager pulling data for multiple end-investors, each underlying authorization is captured the same way. Data minimization is the default — we pull what is in scope, not the wider account.

NDAs are signed where the customer requires it. Logs of who pulled what, when, are part of the deliverable.

Engineering we plan around

Two specifics shape the build, and a third one shapes the maintenance.

• Report-type asymmetry between surfaces. Freedom24's web member area exposes three report types — Broker, Custody, and Trade Report for Tax Return — while the mobile menu surfaces only Broker and Custody, per the platform's own help material. We map both endpoints, sit the tax report behind the web path, and make the output uniform regardless of which surface is reachable on the day. Downstream code does not have to know which client raised the request.
• Multi-currency reconciliation. A Freedom24 account can hold cash in EUR, USD, GBP, HKD and others, with trades denominated in instrument currency and corporate actions sometimes paid in a third. We normalize cash flows to one base currency you pick at integration time, but every leg keeps its native amount, currency, FX rate, source and timestamp. Round-trip checks are part of the test pack, so reconciliation against the broker report is not a surprise at year-end.
• Conformance after portal changes. Freedom24 ships updates regularly. We schedule a conformance check that runs after each release of any size, and on a fixed monthly cadence either way; if a field has moved or a label has changed, we patch the mapping before it reaches your stack. This is part of how we operate, not an extra invoice.

Working with us

A Freedom24 build is usually one to two weeks of work: long enough to confirm the auth flow on a consenting account, map the report endpoints, normalize the multi-currency cash legs, and hand over a tested portfolio feed with the docs above. Source-code delivery starts at $300 and is billed only after the package is in your hands and you have run the tests — open the OpenAPI doc, point the conformance check at a sandbox or your own account, then pay. If you would rather not run anything yourself, the same endpoints sit behind our hosted API and you pay per call with no upfront commitment. Either way, access paperwork, sandbox setup and any NDAs are arranged with you as part of the engagement, not asked of you up front.

The fastest way in is a one-line message on the contact page — the app name (Freedom24), the data you need (positions, trades, tax report, etc.), and whether you want source or hosted. We come back with a scope and a date.

Where this gets used

1. A European wealth-aggregation app pulling Freedom24 positions and cash alongside data from PSD2-side current accounts, so the user sees one net-worth view.
2. A tax-software vendor importing the Trade Report for Tax Return for residents of the EU jurisdictions Freedom24 covers (Germany, France, Spain, Italy and the rest of the local-team list).
3. A family-office back office reconciling Freedom24 custody and broker positions against an internal portfolio system on a monthly close.
4. A robo-advisor offering its existing customers a one-click import of legacy Freedom24 positions during onboarding, with explicit consent capture.

Sources

Mapping built from a read of Freedom24's own help and platform pages and a check of the regulator's framework. The specific items we cite below were opened directly.

• Freedom24 — How to generate your brokerage report (web vs. mobile report types).
• Freedom24 — Why investors trust Freedom24 (CySEC licence, MiFID II, ICF cover).
• CySEC — Approved domains of investment firms (regulator-side check).
• Freedom Holding Corp. — Annual reports (group financial filings, NASDAQ-listed parent).

OpenBanking Studio · interface mapping, May 2026.

Brokers in the same orbit

Other EU-relevant brokerage apps an aggregator or back-office tool is likely to encounter alongside Freedom24. Plain ecosystem context — no ranking implied.

• DEGIRO — Dutch-rooted broker with EU coverage; large statement and portfolio surface behind the login.
• Trade Republic — German neobroker with a deep mobile portfolio and ETF savings plans; statements and order history sit behind the app.
• eToro — multi-asset platform with social/CopyTrading data and a structured account statement export.
• Scalable Capital — Munich-based broker with savings plans and a documented year-end tax report under German tax rules.
• XTB — pan-EU broker with portfolio and trade history surfaces in its xStation app.
• Trading 212 — UK and EU broker with structured statements behind the account.
• Interactive Brokers — global broker with a long-established trader workstation and rich account reports.
• Saxo Bank — Danish multi-asset broker with detailed institutional-grade reports per account.
• Lightyear — newer European broker with a clean app-side data surface.

Things integrators ask first

Does the integration cover all fifteen exchanges Freedom24 routes orders to, or only the main ones?

All of them, when the account itself is enabled for them. The integration treats the exchange as a routed attribute on the trade, not as a separate connector — so US, EU and Asian venues come through the same normalized order and position records. Quirks per venue (lot sizes on HKEX, fractional handling on US listings, settlement day differences) are handled in the mapping layer.

Where does realized P/L come from — only the tax PDF, or trade history?

Both, and they should agree. The Trade Report for Tax Return is the authoritative figure for a given calendar window and is what we cite when reconciling. The trade history feed is what we use for live, intra-period figures, with FX and corporate-action adjustments applied on our side. If they diverge we hold the build until the cause is identified.

How is the multi-currency mess (EUR base, USD/GBP/HKD trades) shaped on the way out?

We normalize to a base currency you choose at integration time. Each cash movement keeps its native amount and currency plus an FX record (rate, source, timestamp); positions report market value in instrument currency and in base. The custody-vs-trading-account split that Freedom24 surfaces in the custody report is preserved — we do not collapse the two.

What happens to the integration when Freedom24 redesigns part of the portal?

We schedule a conformance check that runs after each Freedom24 release of any size, and again on a fixed monthly cadence. The check exercises the auth handshake and a fixture set of report and portfolio calls; anything off is patched before it reaches your stack. This is part of the maintenance arrangement, not an extra.

Talk to us about what you want from Freedom24.

Tell us the app and what you want from its data. We handle the rest — authorization paperwork with the account holder, sandbox or test-account setup, NDAs where they apply. A first build typically lands in one to two weeks. See contact.

Interface evidence

Screens from the Play Store listing, used here as visual reference for the surfaces named above.