Rebasing Capital Gains with the gainSince Parameter

By Gary Kennedy
October 22, 2025

When investors move between tax jurisdictions, capital gains must be split between the period before and after the move. Babylon’s new gainSince parameter makes this possible. By specifying a date, you can recalculate gains as if every holding were re-based at that moment — automatically replacing pre-date transactions with a single notional trade per security per account. The result is an accurate picture of gains arising since the jurisdiction change, while preserving your original trading history.

The challenge of changing jurisdictions

Changing tax residency partway through an investment period introduces a break in capital gains reporting. Most systems assume a continuous holding period, but tax authorities generally require that unrealised gains up to the date of the move be frozen and only subsequent gains be reportable in the new jurisdiction.

Manually reconstructing these calculations — across multiple securities, currencies, and accounts — is both error-prone and time-consuming.

The gainSince parameter

To simplify this, the Babylon capital gains API end-point introduces an optional query parameter called gainSince. This parameter allows users to specify a date that represents the start of a new tax period or jurisdiction.

When gainSince is provided, Babylon automatically:

1. Groups all transactions occurring before the gainSince date, by security and account.
2. Removes these historical trades from the segment’s working set.
3. Inserts synthetic “re-base” entries, one per account per security, representing a notional sale and repurchase at the prevailing market value near the specified date.

This ensures all gains after that point are measured relative to the market price at the jurisdiction change date, effectively simulating a deemed disposal and reacquisition.

API Example

GET /compute/capital-gains?segmentLedger=MyUKSegment&gainSince=2024-07-01

Parameters

Example behaviour

Using gainSince=2024-07-01 instructs Babylon to ignore all transactions before 1 July 2024 in the live calculation, instead generating new notional holdings as if they were acquired on that date. Subsequent sales or purchases are then applied normally, producing capital gains that reflect only post-July activity.

Example scenario

Imagine you move tax residency from the UK to South Africa on 1 July 2024.
You hold shares in two accounts, each containing several securities accumulated over years.

A standard capital-gains calculation would treat these as continuous holdings, mixing pre- and post-move performance.
With gainSince=2024-07-01, Babylon replaces all pre-July trades with synthetic entries priced as of that date — so only gains realised after the move appear in your analysis.

Integration with Segments

The rebasing logic operates within Babylon’s segment model. Each segment represents a coherent group of positions across related accounts and markets.
By rebuilding the segment from the gainSince point forward, we preserve the integrity of segment boundaries while allowing precise cross-jurisdiction comparisons. This is all done on-the-fly, we do not persist the updated segment nor do we copy and persist it. This avoids any confusion in the system.

Why it matters

Tax rules differ widely between jurisdictions, but the principle of “deemed disposal” at change-of-residence is common.
The gainSince parameter operationalises this concept in software — giving users and advisors a reliable, automated way to comply with cross-border capital gains rules without rewriting history.