Pulling pension balances, transactions and fund data out of Standard Life UK

Phoenix Life Limited runs the Standard Life brand, and the app is a thin client over a per-member pension ledger: each login resolves to plan references, a current valuation, a transaction history, and a set of fund holdings that re-price once a day. That shape is what makes it worth integrating — the data is structured, it is account-scoped, and it changes on a predictable rhythm rather than at random.

For a system that needs to hold a current copy of someone's Standard Life pension — a retirement-planning tool, an adviser back office, a money-aggregation product — the practical problem is not a one-time read. It is staying in step with a ledger that grows by a few rows a day. So the route we lead with is a polling-and-cursor design against the transaction surface, paced to the daily valuation update, under the member's own authorization. Below: what the app holds, the authorized ways in, the sync code, and what you get back from us.

What the app actually holds

These map to surfaces a logged-in member sees, named the way Standard Life names them where the app's own description does so.

Authorized ways in

Three routes genuinely apply to this app. We arrange the access each one needs together with you during onboarding — a consenting member account or a provider sandbox — so none of this is something you have to line up before we begin.

1 · Member-consented interface integration

With a member's authorization, we drive the same authenticated interface the app uses and normalize what comes back. This reaches everything in the table above, because it reaches what the member can see. Effort is moderate; durability is good as long as we keep a thin validation layer watching for interface changes. For most aggregation and planning use cases, this is the route we recommend — it is the only one that returns the full surface today.

2 · Protocol analysis under your authorization

Where you need a documented, vendor-independent contract — request shapes, the token and session chain, error semantics — we analyze the app's own traffic and hand back a written spec plus client code. This is the durable foundation under route 1; it is what makes the integration something an engineer can reason about rather than a black box.

3 · UK Open Finance, as it arrives

Pensions are explicitly named in the FCA's open finance roadmap as a future smart-data scheme, with a first discussion paper expected in Q4 2026 (per the FCA). When a pensions scheme lands, consented programmatic access becomes the cleanest long-run path, and the spec we write today is built to swap onto it. We treat this as the direction of travel, not as something to wait for.

The delta poll, concretely

The transaction list is the natural sync key: it only appends, so a stored cursor lets each run fetch just what is new, and the daily valuation rides along on the same response. Field names and values here are illustrative, confirmed and pinned against the live interface during the build.

# Session established during onboarding (consented portal auth / OAuth2 bearer)
GET /members/{memberId}/plans/{planId}/transactions?since_cursor=eyJ0&page_size=100
Authorization: Bearer <access_token>

200 OK
{
  "plan_id": "AMPP-****",                       # plan reference as shown in-app
  "valuation": { "amount": 48213.55, "currency": "GBP", "as_of": "2026-05-30" },
  "transactions": [
    { "id": "txn_8841", "type": "CONTRIBUTION", "amount": 250.00, "effective_date": "2026-05-28" },
    { "id": "txn_8842", "type": "FUND_SWITCH",  "fund": "SL Sustainable Multi Asset", "units": -120.44 }
  ],
  "next_cursor": "eyJ0...",                      # opaque; persist, replay on next poll
  "has_more": false
}

# --- daily delta loop (Python sketch) ---
def sync(plan, store):
    cursor = store.get_cursor(plan.id)           # resume where we stopped
    while True:
        page = client.transactions(plan.id, since_cursor=cursor, page_size=100)
        for txn in page["transactions"]:
            store.upsert(plan.id, txn["id"], txn)  # keyed on txn id; re-runs settle, never duplicate
        store.set_valuation(plan.id, page["valuation"])
        cursor = page["next_cursor"]
        store.set_cursor(plan.id, cursor)          # checkpoint after each page
        if not page["has_more"]:
            break

Because the upsert is keyed on the transaction id and the cursor is checkpointed per page, a poll that dies mid-run resumes cleanly on the next pass without double-counting a contribution.

What lands in your repo

The headline deliverable is code that runs against your own consented test member, not a slide deck.

• Runnable client source in Python and Node.js: auth handling, the transaction delta loop above, plan-valuation and fund-holdings reads, mailbox capture.
• Webhook / scheduler glue for the daily sync, with cursor persistence and resumable checkpoints wired in.
• Automated tests that exercise each surface against a sandbox or consented account, so an interface change shows up as a failed assertion rather than a quiet gap in your data.
• A normalized schema mapping plans, valuations, transactions and funds into stable types your system can rely on across providers.
• An OpenAPI / Swagger spec and an auth-flow report documenting the token and session chain — secondary to the code, but there so the integration is auditable.
• Interface documentation and data-retention guidance covering consent records, logging, and minimization.

Consent and the rules around pension data

Standard Life is operated by Phoenix Life Limited, which the app's legal text states is authorised by the PRA and regulated by the FCA and PRA. The dependable basis for everything here is the member's own authorization to read their plan — explicit, logged, revocable, and scoped to the data domains a use case actually needs.

Two UK-specific points shape the work. First, the pensions dashboards ecosystem that providers must connect to (a 31 October 2026 deadline, per the FCA and the Pensions Dashboards Programme) is a narrow find-and-view dataset for authorized dashboard operators — useful context, but scoped to dashboards rather than to general integration. Second, open finance for pensions is still forward-looking in the UK: the FCA's roadmap names pensions among future smart-data schemes under the Data (Use and Access) Act, with a first discussion paper flagged for late 2026. We build to member consent now and keep the design ready to ride a pensions scheme when one is finalized. We work under NDA where you need one, keep consent and access logs, and minimize what we pull to the fields in scope.

Things we map so they don't bite later

A few quirks of this app are worth handling deliberately rather than discovering in production.

• Product coverage gaps. The app's own notes say it does not cover WRAP or Aberdeen Standard Capital, and that some With Profits policies, Bonds and Investment Fund products cannot be viewed. We map eligibility per product and return a coverage flag, so an unsupported plan is reported back rather than silently producing an empty record.
• Workplace vs personal payment routing. The description notes that not all products support payments through the app, and that workplace members may be directed to an employer; regular-payment changes draw from the bank account held on file. We model the payment-source rules per plan type so contribution data is attributed to the right source.
• Daily valuation rhythm. Fund values and daily changes update once per cycle. We pace the poll to that cadence and cursor on transactions, so we are not re-pulling an unchanged ledger many times a day or missing the one daily price move.

Where teams actually use this

• A retirement-planning app that mirrors a member's Standard Life plan value and contributions to drive projections, refreshed daily.
• An adviser back office consolidating a client's Standard Life pension alongside other providers into one normalized view.
• A money-aggregation product adding pensions to its net-worth picture, reading valuation and fund holdings under consent.
• A document workflow that captures secure-mailbox correspondence and attachments into a client record.

App screens

Store screenshots, used here to ground the surfaces described above. Select to enlarge.

What was checked, and where

Surfaces were read from the app's Google Play description and Standard Life's own help material; the regulatory picture from FCA and Pensions Dashboards Programme primary pages, checked 1 June 2026. Worth opening directly:

• Standard Life — App & Dashboard help
• FCA — connecting to the pensions dashboards ecosystem
• Pensions Dashboards Programme — data standards
• FCA — open finance roadmap

Compiled 2026-06-01 by the OpenFinance Lab interface team.

Pensions and savings apps in the same space

Same-category UK apps an aggregator would likely integrate alongside Standard Life — neutral context, not a ranking.

• PensionBee — consolidates old pensions into one plan; holds per-member balance, contributions and transfer history.
• Penfold — digital personal and self-employed pensions; holds contributions, fund choice and projections.
• Aviva — large insurer with workplace and personal pensions; holds plan value, fund and contribution data.
• Scottish Widows — workplace and personal pensions; holds valuations, fund performance and statements.
• Royal London — mutual insurer; holds pension and protection plan data per member.
• Nutmeg — managed investment and pension portfolios; holds positions, performance and contributions.
• Hargreaves Lansdown — investment platform and SIPP; holds holdings, transactions and cash balances.
• AJ Bell — SIPP and dealing platform; holds portfolio positions, orders and statements.
• Vanguard Investor UK — low-cost SIPP and ISA; holds fund holdings, contributions and valuations.

Questions integrators ask

How often does Standard Life data actually change, and how do you keep a synced copy current?

Fund valuations move once a day, and contributions or switches append over time rather than rewriting old rows. We poll on a daily cadence aligned to that valuation cycle and keep a cursor on the transaction feed, so each run pulls only new activity instead of re-reading the whole plan history.

Can you reach workplace pensions as well as personal Standard Life plans?

Both, with caveats we map up front. Payments on a workplace plan may route through an employer rather than the member's own bank account, and the app itself does not cover WRAP or some With Profits, Bond and Investment Fund products. We return a coverage flag per plan so unsupported products are reported, not silently dropped.

Which pension data can be read for a member who has authorized access?

Plan valuation and daily fund changes, recent transactions and contributions, fund holdings and switches, retirement date, beneficiaries, charges and discounts, and secure mailbox messages with attachments — the same surfaces a member sees in the app, normalized into a stable schema.

Does the UK pensions dashboard connection give you a usable data feed?

Not for general integration. The dashboards ecosystem that providers connect to (deadline 31 October 2026, per the FCA and the Pensions Dashboards Programme) exposes a narrow find-and-view dataset to authorized dashboard operators, not a general integration channel. Our dependable basis is the member's own authorization to read their plan.

A first working pull of plan value and transactions against a consented test member typically lands inside one to two weeks. We deliver the runnable source and documentation outright from $300, paid only after delivery once you are satisfied; or you call our hosted endpoints and pay per call, nothing upfront. Tell us the plan data you need and what you're building, and we will scope it — start a conversation here.