DEV Community: Amanda Vance

How a Forex Trading Cost Calculator Works: Spread, Commission and Swap in Python

Amanda Vance — Sat, 10 Oct 2026 20:55:22 +0000

People often ask what happens under the hood when they type numbers into an automated forex trading fee calculator. This post answers that by building the same underlying calculation engine from scratch in Python.

The formulas below represent the standard mathematical models used across institutional and retail markets. The prices in the examples are static figures for illustration, not live API quotes.

The Three Costs of a Trade

According to foreign exchange turnover data tracked by institutions like the Bank for International Settlements (BIS), retail currency volume continues to scale across both dealer networks and ECN venues. Every trade executed across these networks carries up to three distinct costs:

Spread: The gap between the bid and ask price. A trader pays this the exact moment they execute the order.
Commission: A fixed fee per lot, charged predominantly on raw or ECN-style accounts. Brokers usually quote this per "round turn," meaning it covers both opening and closing the position.
Swap: The rollover charge (or credit) for holding a position past the daily settlement cutoff. A breakdown of the underlying rate differentials is detailed in Investopedia's currency swap guide.

Everything else—platform subscription fees, deposit and withdrawal fees, and inactivity charges—sits outside the execution itself, so the calculator ignores them.

Step 1: Pip Size and Pip Value

A pip is the standardized unit for measuring exchange-rate price moves. As outlined in Investopedia's explanation of pips, for most currency pairs, a pip equals 0.0001. For pairs quoted against the Japanese Yen (JPY), it equals 0.01.

Pip value depends entirely on the position's lot size and the quote currency (the second currency in the pair). One standard lot equals 100,000 units of the base currency. To report everything cleanly in USD, the code below converts the quote currency utilizing a small static rate dictionary. We structure the data structures using standard Python dataclasses:

from dataclasses import dataclass

# Illustrative static prices for the examples below.
RATES = {
    "EURUSD": 1.1000, "GBPUSD": 1.3000, "USDJPY": 150.00, "USDCHF": 0.9000,
    "USDCAD": 1.3500, "AUDUSD": 0.6500, "NZDUSD": 0.6000,
    "EURJPY": 165.00, "GBPJPY": 195.00, "EURGBP": 0.8462,
}
LOT = 100_000

def pip_size(pair: str) -> float:
    return 0.01 if pair.endswith("JPY") else 0.0001

def to_usd(currency: str) -> float:
    """USD value of one unit of `currency`, using the table above."""
    if currency == "USD":
        return 1.0
    if f"{currency}USD" in RATES:
        return RATES[f"{currency}USD"]
    return 1.0 / RATES[f"USD{currency}"]

def pip_value_usd(pair: str, lots: float) -> float:
    quote = pair[3:]
    return LOT * pip_size(pair) * lots * to_usd(quote)

def notional_usd(pair: str, lots: float) -> float:
    return LOT * lots * to_usd(pair[:3])

def rollovers(days: int, start_weekday: int) -> int:
    """Nights charged. Weekday 0 = Monday. Wednesday night counts triple."""
    nights = 0
    for d in range(days):
        wd = (start_weekday + d) % 7
        if wd in (5, 6):          # Saturday, Sunday: no rollover
            continue
        nights += 3 if wd == 2 else 1
    return nights

The only part requiring care is the to_usd function. For a pair like GBPJPY, the quote currency is Yen. The code finds USDJPY in the dictionary and mathematically inverts it. A production-ready calculator would pull live quotes via an exchange API rather than a static dictionary.

Step 2: The Cost Formulas

With the pip value established, calculating each specific cost requires just one line of arithmetic:

Spread cost = spread in pips × pip value
Commission = commission per lot × lots
Swap cost = swap in pips per night × pip value × nights charged

Total cost equals the sum of the three. Dividing that total cost by the pip value reveals the "break-even distance"—the exact number of pips the market price must move in your favor just to bring the trade's P&L back to zero.

@dataclass
class Costs:
    spread: float
    commission: float
    swap_cost: float
    total: float
    break_even_pips: float
    pct_of_notional: float

def trading_cost(pair, lots, spread_pips, commission_per_lot=0.0,
                 swap_pips_per_night=0.0, days=0, start_weekday=0) -> Costs:

    pv = pip_value_usd(pair, lots)
    spread = spread_pips * pv
    commission = commission_per_lot * lots

    # Broker swap: negative usually means a charge, so cost is its opposite
    swap_cost = -swap_pips_per_night * pv * rollovers(days, start_weekday) + 0.0 
    total = spread + commission + swap_cost

    return Costs(
        spread=spread,
        commission=commission,
        swap_cost=swap_cost,
        total=total,
        break_even_pips=total / pv,
        pct_of_notional=100 * total / notional_usd(pair, lots),
    )

Step 3: Counting Swap Nights

Swap calculations often trip up developers because the number of nights held does not match calendar days. Standard spot FX trades settle on a $T+2$ basis, as explained in the Corporate Finance Institute guide to forex rollover.

Weekends carry no rollover execution of their own. To compensate, brokers charge a "triple swap" on a designated weekday (almost universally Wednesday) to account for settlement rollover across Saturday and Sunday. The rollovers function defined above handles both conditions.

A trade opened on Tuesday and held for three days hits Tuesday, Wednesday (which counts three times), and Thursday—totaling 5 nights of swap charges.

Conversely, a trade opened on Friday and held for five days hits Friday night, skips Saturday and Sunday entirely, then hits Monday and Tuesday—totaling just 3 nights. In a test run, rollovers(5, 4) returns 3.

Brokers typically quote swap rates as signed values where a negative figure represents a debit. The code flips the sign so that charges register as positive costs while interest credits reduce the net fee.

Worked Examples

These are the exact numbers the Python script outputs. You can manually verify each calculation.

1. Standard Account: EUR/USD, 1 lot, 1.2 pip spread

Pip value: $10.00
Spread cost: 1.2 × 10 = $12.00
Total: $12.00, break-even 1.2 pips (0.0109% of total trade value)

2. ECN Account: EUR/USD, 1 lot, 0.1 pip spread, $7 round-turn commission

Spread cost: 0.1 × 10 = $1.00
Commission: $7.00
Total: $8.00, break-even 0.8 pips (0.0073% of total trade value)

The ECN account runs cheaper in this scenario, which is typical when executing a full 1.0 lot of trading volume. That spread advantage narrows significantly on fractional micro-lots if a brokerage enforces minimum ticket commissions.

3. GBP/JPY: 0.5 lot, 1.5 pip spread, swap of -0.8 pips a night, held 3 days from Tuesday

Pip value: 100,000 × 0.01 × 0.5 ÷ 150 = $3.33
Spread cost: 1.5 × 3.33 = $5.00
Swap: 0.8 × 3.33 × 5 nights = $13.33
Total: $18.33, break-even 5.5 pips

In this swing scenario, the holding costs exceed the initial spread. This demonstrates why rollover rates dictate long-term holding strategies while having minimal impact on intraday scalps.

What the Calculator Leaves Out

A few variables change real-world execution costs that cannot be hardcoded into a static script:

Volatility and Liquidity Spikes: Spreads widen rapidly around Tier-1 macroeconomic releases and during the daily 5:00 PM EST rollover. The inputs in this script represent median averages rather than guaranteed fills.
Broker Rounding: Brokerage platforms round internal pip fractions and daily interest debits differently, creating minor cent-level discrepancies against manual calculations.
Swap-Free Accounts: Islamic or swap-free accounts replace variable interest debits with fixed administrative fees or eliminate overnight holding costs under specific conditions.

To evaluate these variables in a live interface, use the browser-based BrokerCatalogue fee calculator. It processes the pair, position sizing, account structure, spread, commission, and swap rates directly, displaying the net cost, percentage impact, and required break-even pip distance.

Try it

Copy the Python script, configure the RATES dictionary with current market quotes, and run trading_cost using your broker's published schedule to compare fee profiles across multiple platforms.

How To Build Algorithmic Trading Systems in the US: A Developer's Guide to Forex APIs"

Amanda Vance — Sun, 27 Sep 2026 18:38:00 +0000

If you are a developer building an algorithmic trading system, connecting to a forex broker’s API outside the United States is relatively trivial. You open a WebSocket for pricing, POST an order to a REST endpoint, and manage your tickets independently.

If you deploy that exact same code on a US-regulated broker account, it will almost certainly crash, throw a 400 Bad Request, or liquidate the wrong positions.

The US retail forex market is governed by the Commodity Futures Trading Commission (CFTC) and the National Futures Association (NFA). Their compliance rules dictate order routing at the server level, fundamentally breaking how standard algorithmic architectures handle risk management. F

urthermore, the regulatory capital requirements are so high that only five compliant retail brokers remain in the US market.

Refer to this developer’s guide to navigate US execution logic and an architectural audit of the five APIs you can legally build on.

The Code-Breakers: FIFO and No-Hedging

If you are migrating a trading bot from an offshore broker to a US broker, two server-side routing laws will break your logic:

1. The FIFO Mandate (First-In, First-Out)

NFA Rule 2-43(b) dictates that if you have multiple open positions of the exact same size on the same currency pair, the oldest ticket must be closed first.

Imagine your Python script scales into a EUR/USD position at two different price levels:

Ticket_A (Oldest): Long 10,000 units
Ticket_B (Newest): Long 10,000 units

If Ticket_B hits its profit target and your script sends a DELETE /accounts/{accountID}/trades/{Ticket_B}/close request, the US broker's API will reject it. You cannot selectively close a newer ticket.

The Programmatic Workaround: Because FIFO only applies to positions of the exact same size, developers offset their lot sizes by micro-amounts to restore ticket independence.

Entry 1: 10,000 units
Entry 2: 10,001 units
Entry 3: 10,002 units

Because the units differ, the broker's matching engine treats them as distinct liabilities, allowing your script to close them in any sequence.

2. The No-Hedging Rule

You cannot hold simultaneous long and short positions on the same pair. If your script holds a long EUR/USD position and POSTs a sell order for the same pair, the broker's server will not open a new short ticket—it will execute the order by netting (closing) your existing long position.

The 5 Compliant US Broker APIs (2026 Audit)

To ensure I'm building on legal infrastructure, I track active NFA license data using independent directories like BrokerCatalogue. Based on current NFA capital filings, here are the only five compliant retail endpoints, ranked by Developer Experience (DX).

1. OANDA (The v20 REST API)

OANDA has arguably the best developer ecosystem in the retail space. Their v20 REST API is heavily documented, utilizes standard HTTP verbs, and returns clean JSON. They provide officially supported wrappers for Python, Go, and Node.js.

API Protocol: REST, streaming WebSockets for pricing.
Authentication: Personal Access Token (Bearer Auth).
Why Devs Like It: You can spin up a sandbox environment (fxTrade Practice) with fake money and live market data in about three minutes.

Example v20 Order POST:

{
  "order": {
    "units": "100",
    "instrument": "EUR_USD",
    "timeInForce": "FOK",
    "type": "MARKET",
    "positionFill": "DEFAULT"
  }
}

2. FOREX.com (StoneX Group)

Backed by StoneX Group, FOREX.com is highly appealing if you need to scale up to institutional infrastructure. They offer a standard REST API for retail accounts, but high-volume systematic traders can request access to their FIX (Financial Information eXchange) API.

API Protocol: REST for retail, FIX 4.4 for high-volume accounts.

Why Devs Like It: If you are building High-Frequency Trading (HFT) algorithms, REST APIs carry too much HTTP overhead. Connecting directly to their FIX API via a VPS located in the Equinix NY4 data center drastically reduces millisecond latency.

3. Interactive Brokers (TWS API & Web API)

Interactive Brokers (IBKR) aggregates liquidity from 17 interbank dealers. The infrastructure is incredibly powerful, but the Developer Experience is notoriously brutal.

API Protocol: TWS API (requires a running instance of their desktop software or IB Gateway), Client Portal REST API, FIX API.

Why Devs Like It: True interbank liquidity. If you are building a multi-asset quantitative system (trading FX, options, and global equities simultaneously), IBKR is the only API that can handle it seamlessly. Just be prepared to fight with their Java/Python wrappers.

4. Charles Schwab (thinkorswim API)

Following the integration of TD Ameritrade, the beloved TD Ameritrade API was migrated to the Schwab Developer portal.

API Protocol: REST.

Why Devs Like It: Access to the thinkorswim ecosystem. While not strictly a forex-first API, it allows developers to pull highly accurate historical tick data and integrate forex positions into broader equity/options portfolios.

5. tastyfx (IG Group REST API)

Formerly known as IG US, tastyfx operates on IG Group's global API infrastructure.

API Protocol: REST for execution, Lightstreamer for live pricing.

Why Devs Like It: They offer over 80 currency pairs (the widest in the US). If you are building a statistical arbitrage bot that relies on obscure minor or exotic pairs, tastyfx provides the necessary market breadth.

Finding the Right API for Your Tech Stack Do not commit to writing a massive codebase until you verify the broker supports the execution model your algorithm requires.

If you need to filter these providers based on API availability, VPS hosting support, and underlying execution models (A-Book vs B-Book), use BrokerCatalogue's interactive Broker Finder Tool. It allows developers to filter the US regulatory landscape dynamically based on verified infrastructure data.

If you are building your first trading bot, start with OANDA's v20 sandbox. If you are migrating a latency-sensitive institutional model, look into FOREX.com's FIX documentation.

Building a Scoring Algorithm to Rank Brokers by Regulation and Spreads

Amanda Vance — Fri, 11 Sep 2026 10:24:26 +0000

Retail traders require objective data to select financial brokers. Directory websites must rank platforms using verifiable metrics to replace subjective opinions.

A programmatic scoring algorithm removes human bias from broker reviews. Developers can build a Python pipeline to calculate a mathematical trust score.

The system evaluates two primary data points. It checks regulatory licenses and analyzes average trading spreads.

Financial authorities issue specific tier ratings for compliance. The UK Financial Conduct Authority (FCA) and Australian Securities and Investments Commission (ASIC) represent top-tier regulators.

The FCA provides a free public API to verify firm authorization. Developers must register at the FCA Developer Portal using an email address to receive an API key.

The FCA Register uses a unique Firm Reference Number (FRN) to identify every regulated entity. The API returns the legal organization name and its current authorization status.

The algorithm assigns point values to these regulatory licenses in a central database. A valid FCA license grants the maximum regulatory score.

ASIC regulation provides another strong trust signal for global brokers. The scoring model assigns a slightly lower point value for Australian licenses.

Trading costs represent the second half of the scoring algorithm. Lower spreads save traders money on every execution.

The logic penalizes brokers for maintaining wide spreads. The script multiplies the average EUR/USD pip spread by a penalty factor.

The following Python logic calculates the final broker rank.

def calculate_broker_score(fca_regulated: bool, asic_regulated: bool, avg_spread: float) -> dict:
    base_score = 0

    # Assign points based on regulatory tiers
    if fca_regulated:
        base_score += 50
    if asic_regulated:
        base_score += 30

    # Deduct points for higher trading spreads
    spread_penalty = avg_spread * 10
    final_score = base_score - spread_penalty

    return {
        "regulatory_points": base_score,
        "spread_penalty": spread_penalty,
        "total_trust_score": max(0, final_score)
    }

# Example calculation for a regulated broker with a 1.2 pip spread
# score = calculate_broker_score(True, True, 1.2)
# print(score)

This function accepts boolean values for regulatory status and a float for the spread. It outputs a standardized integer score.

Developers can run this function across an entire broker database. The system sorts the resulting scores in descending order to generate public rankings.

Publishing the ranking methodology builds trust with retail investors. Users can verify the exact criteria determining the top placements.

A cron job automates this pipeline to run nightly. This schedule ensures the public directory always reflects the latest regulatory status and spread averages.

See a live implementation of this algorithm at Broker Catalogue. Review the complete directory structure on the Broker Catalogue Developer Hub.