DEV Community: PyDev

Building a Production-Ready Risk Management Engine for Algorithmic Trading

PyDev — Fri, 17 Jul 2026 12:39:43 +0000

Part: 4 of 18

About this series

This series documents the engineering evolution of a production-ready algorithmic trading platform in Python. It focuses on architecture, state management, execution, real-time data processing, persistence, and the engineering decisions that transformed a simple trading bot into a production-ready platform.

In Part 3: Building a Production-Ready Position Manager for Algorithmic Trading, I described the component responsible for maintaining persistent position state throughout the entire trade lifecycle.

Read Part 3 here:

https://dev.to/pydevtop/building-a-production-ready-position-manager-for-algorithmic-trading-55n4

The Position Manager could remember every open position.

The next challenge was deciding what should happen to those positions as market conditions continuously changed.

Project Website

This article is part of the engineering story behind the Bybit Signal Trading Platform.

If you'd like to learn more about the project, see additional screenshots, features and technical details, visit:

https://py-dev.top/application-software/bybit-signal-trading-bot

The Problem Was Never Stop Loss

If someone had asked me during the first weeks of development where the Stop Loss logic should live, I wouldn't have hesitated.

Inside the Trade Execution Engine.

Where else?

The engine already received TradingView webhooks.

It validated incoming requests.

It calculated Take Profit.

It opened positions.

Adding one more calculation felt completely natural.

The implementation looked something like this.

signal = receive_signal()

validate(signal)

entry = execute_order(signal)

stop_loss = calculate_stop_loss(entry)

take_profit = calculate_take_profit(entry)

Simple.

Readable.

Everything related to opening a trade existed in one place.

At that moment there was absolutely no reason to introduce another component.

There was only one trading pair.

Only one open position.

No persistence.

No restart recovery.

No Break Even.

No Trailing Stop.

No Spot/Futures differences.

No Reverse Signal.

No Telegram controls.

No analytics.

The architecture matched the complexity of the platform.

And that is exactly why it was dangerous.

The biggest architectural mistakes rarely look like mistakes when a project is small.

They usually look elegant.

Why Simple Systems Lie

One of the biggest traps in software engineering is believing that an architecture proven by a prototype is automatically suitable for production.

It isn't.

Prototype architectures optimize for speed.

Production architectures optimize for change.

Those are very different goals.

During the first prototype almost every decision looked correct.

Need another validation?

Add another if.

Need another parameter?

Pass another argument.

Need another calculation?

Place it below the previous one.

Nothing felt wrong because every new feature increased complexity by only a few lines of code.

Then months passed.

The project kept growing.

The first partial Take Profit appeared.

Soon after, Break Even was added.

Then Trailing Stop.

After that came Reverse Signals.

Dry Run mode.

Testnet.

Mainnet.

Spot trading.

Futures trading.

SQLite persistence.

Restart recovery.

Telegram control panel.

WebSocket market data.

Every feature looked completely independent.

Every pull request looked small.

But something interesting was happening.

The execution engine was slowly becoming responsible for things that had nothing to do with execution.

It started validating business rules.

Tracking position state.

Evaluating exposure.

Reacting to market events.

Updating persistent storage.

Managing lifecycle transitions.

Generating reports.

Nothing broke.

The architecture simply became harder to understand every month.

That kind of failure is much more dangerous than an exception.

Because nobody notices it immediately.

Execution Is Not Risk

The turning point happened when I stopped looking at the code and started looking at the questions the platform was trying to answer.

The trading strategy answered one question.

Should we open a position?

The execution engine answered another.

How do we open the position?

Then another question quietly appeared.

Are we still allowed to open this position?

At first glance those questions seem related.

Architecturally they are completely different.

A trading signal is an opinion.

Risk management is a policy.

One predicts the market.

The other protects the account.

Mixing those responsibilities eventually creates a component that is difficult to extend because every new feature touches existing logic.

Instead, the execution pipeline gradually evolved into something much cleaner.

TradingView Signal
        │
        ▼
Trade Execution Engine
        │
        ▼
Risk Evaluation
        │
   Approve / Reject
        │
        ▼
Position Manager
        │
        ▼
Exchange

Separating those responsibilities simplified almost every other component.

The Evolution of the Trade Execution Engine

The first version of the execution engine was surprisingly small.

Receive Signal
      │
      ▼
Validate
      │
      ▼
Create Order
      │
      ▼
Exchange

That architecture survived exactly until the platform became stateful.

Once positions started living longer than a single order, everything changed.

Now the engine needed information that wasn't available anymore.

Questions appeared continuously.

Is TP1 already reached?

Is Break Even active?

Did Trailing Stop move?

How much quantity remains?

Is this Spot or Futures?

Has the application restarted?

Is another position already open?

None of those questions belonged to execution.

They belonged to state.

Or policy.

Or lifecycle.

Yet the execution engine knew about all of them.

Every new responsibility increased coupling between components.

Eventually changing one feature meant reading code completely unrelated to that feature.

That was a clear indication that the architecture had reached its limits.

When "One More if" Became an Architectural Problem

I don't remember the exact commit where the design became problematic.

There wasn't one.

Architectural debt rarely arrives in a single pull request.

It grows one harmless decision at a time.

It usually starts like this.

if tp1_hit:
    move_stop_loss()

A week later.

if trailing_enabled:
    update_trailing_stop()

Another week.

if reverse_signal:
    close_position()

Then.

if dry_run:
    simulate_order()
else:
    execute_order()

None of those conditions are incorrect.

The problem is that every new condition teaches the component another responsibility.

After dozens of iterations the execution engine wasn't executing anymore.

It was becoming the platform itself.

That violated one of the oldest principles in software architecture.

A component should have a single reason to change.

The solution was not deleting those conditions.

The solution was asking a different question.

Which component should own this decision?

That question changed the architecture far more than any refactoring tool ever could.

Looking Beyond Stop Loss

By this point it became obvious that Stop Loss had never been the real problem.

Stop Loss was simply the first visible symptom.

The real issue was ownership.

Who owns trading state?

Who owns execution?

Who owns lifecycle?

Who owns policy?

Answering those questions eventually produced independent components that could evolve without constantly breaking each other.

The Position Manager became responsible for remembering.

The Trade Execution Engine returned to executing.

And risk slowly became something much larger than a single Stop Loss calculation.

In the next section we'll explore how position state fundamentally changed the entire risk model, and why introducing Break Even, Trailing Stop, and partial Take Profit forced the platform to think about risk as a continuously evolving process rather than a single calculation performed when a trade is opened.

flowchart LR
    TV[TradingView Signal]
    TE[Trade Execution Engine]
    RM[Risk Evaluation]
    PM[Position Manager]
    EX[(Exchange)]

    TV --> TE
    TE --> RM
    RM -->|Approved| PM
    RM -->|Rejected| TE
    PM --> EX

Position Manager and Risk

The previous chapter introduced the Position Manager as the component responsible for remembering the current state of every open position.

At first glance, that doesn't sound related to risk management.

It is.

In fact, the Position Manager became the foundation that made meaningful risk evaluation possible.

Without persistent position state, every incoming market update would have to be treated as if it were the first one.

That isn't how real trading platforms work.

Risk changes over time.

The Position Manager tells us where the position currently is.

The Risk layer decides what should happen next.

Those responsibilities complement each other.

They should never be merged.

                Position State
                       │
                       ▼
              Position Manager
                       │
        ┌──────────────┴──────────────┐
        ▼                             ▼
 Trade Execution Engine        Risk Evaluation
        │                             │
        └──────────────┬──────────────┘
                       ▼
                    Exchange

One component remembers.

The other evaluates.

That distinction dramatically reduced coupling throughout the platform.

Break Even Changed Everything

Initially Stop Loss was static.

The position opened.

The Stop Loss price was calculated.

Nothing changed afterwards.

That approach survived exactly until Break Even was implemented.

Once the first Take Profit had been reached, the original Stop Loss no longer represented the platform's understanding of acceptable risk.

The position had already realized profit.

The remaining quantity was smaller.

The maximum acceptable loss had changed.

The Risk layer no longer asked:

Where is the Stop Loss?

Instead it asked:

What is the correct risk profile now?

That is a much more interesting question.

Break Even was not simply another price calculation.

It represented a transition between two completely different lifecycle states.

Position Open
      │
      ▼
 Full Exposure
      │
      ▼
 TP1 Reached
      │
      ▼
 Break Even Activated
      │
      ▼
 Reduced Risk

The Position Manager stored the transition.

The Risk layer interpreted it.

The execution engine simply followed instructions.

Every component stayed focused on its own responsibility.

Trailing Stop Is Continuous Risk Evaluation

Trailing Stop introduced another architectural shift.

Unlike Break Even, which happens once, Trailing Stop continuously reacts to market movement.

Every price update potentially changes the exit conditions.

That meant risk was no longer evaluated only when a signal arrived.

It also had to be evaluated while the position was already open.

The platform gradually evolved from signal-driven processing into event-driven processing.

Every market update became another opportunity to reduce exposure.

The Position Manager remembered the highest price for long positions and the lowest price for short positions.

The Risk layer compared those values with the configured trailing percentage.

Only then could it determine whether the stop should move.

Notice what did not happen.

The Trade Execution Engine never needed to know how the trailing calculation worked.

It simply received a decision.

position = position_manager.get(symbol)

decision = risk_manager.evaluate(position, current_price)

if decision.action == "move_stop":
    execution_engine.update_stop(decision.new_stop)

That tiny separation made future changes significantly easier.

When trailing logic changed, the execution engine remained untouched.

When order execution changed, trailing logic remained untouched.

The dependency became one-directional.

Instead of every component understanding every rule, each component understood only its own domain.

Reverse Signals Are Risk Decisions

Reverse Signals looked like an execution feature.

Receive an opposite signal.

Close the current position.

Open another one.

Simple.

Until existing positions entered the picture.

What happens if TP1 has already been reached?

What if Trailing Stop is active?

Should the platform immediately reverse?

Or should it close the remaining quantity first?

What if multiple markets behave differently?

Those questions are not execution questions.

They are risk questions.

The execution engine should never decide whether abandoning a profitable position is acceptable.

Its responsibility is simply to execute whatever decision has already been made.

That realization simplified the architecture again.

Instead of embedding more business rules inside order execution, Reverse Signal became another policy evaluated before execution.

Incoming Signal
       │
       ▼
Current Position
       │
       ▼
Risk Evaluation
       │
 Close?
 Ignore?
 Reverse?
       │
       ▼
Execution Engine

As the platform matured, execution became progressively smaller.

Policy became progressively smarter.

That is exactly the direction healthy architectures tend to evolve.

Event-Driven Risk

One of the most significant architectural improvements happened almost accidentally.

Originally the platform reacted only to incoming TradingView webhooks.

Eventually it reacted to events.

That difference sounds subtle.

It wasn't.

Instead of repeatedly asking every component for information, the platform started broadcasting events.

Examples included:

Position Opened
Position Closed
TP1 Reached
Break Even Activated
Trailing Stop Updated
Stop Loss Triggered
Reverse Signal Received

Every component reacted only to the events it actually understood.

flowchart LR

Signal --> Execution

Execution --> PositionOpened

PositionOpened --> PositionManager

PositionOpened --> Risk

MarketPrice --> Risk

Risk --> TrailingUpdated

TrailingUpdated --> Execution

Execution --> Exchange

The architecture became less dependent on direct function calls.

Instead, components communicated through meaningful events.

That reduced coupling and made future extensions considerably easier.

Adding another lifecycle event no longer required modifying every existing component.

Only interested components reacted.

Everyone else ignored it.

That is one of the strongest characteristics of production-ready event-driven systems.

Testing Strategy Changed Completely

One unexpected benefit of separating responsibilities was testing.

The earliest versions of the platform were difficult to test.

Every new feature eventually required exchange connectivity.

Eventually unit tests became integration tests.

That slowed development considerably.

After introducing dedicated responsibilities, testing became almost trivial.

The Position Manager could be tested independently.

The Risk layer could be tested independently.

The execution engine could be mocked.

Instead of building entire trading sessions, tests became deterministic.

position = Position(
    entry_price=62000,
    remaining_qty=0.5,
    tp1_hit=True,
    trailing_active=False
)

decision = risk_manager.evaluate(
    position,
    current_price=63250
)

assert decision.action == "move_stop"

Notice what is missing.

No exchange.

No API credentials.

No WebSocket connection.

No TradingView.

No market replay.

Only deterministic input.

Deterministic systems produce deterministic tests.

That dramatically reduced debugging time and increased confidence before every release.

Perhaps the biggest lesson wasn't about Stop Loss at all.

It was about ownership.

Once every component became responsible for only one problem, testing stopped being an obstacle and became another engineering tool.

Production Lessons

Looking back, one of the biggest surprises wasn't discovering a better algorithm.

It was discovering how little algorithms matter if the surrounding architecture cannot support them.

Early in the project I spent far more time thinking about indicators than software design.

EMA periods.

RSI thresholds.

MACD parameters.

Take Profit percentages.

Trailing distances.

Those decisions certainly influence trading performance.

But none of them determine whether the platform is maintainable six months later.

Architecture does.

The most valuable engineering lesson from this project wasn't learning how to calculate risk.

It was learning how to organize it.

Every production feature eventually forced another architectural decision.

Partial Take Profit required persistent state.

Break Even required lifecycle transitions.

Trailing Stop required continuous evaluation.

Reverse Signals required policy decisions.

Analytics required historical persistence.

Restart recovery required durable storage.

None of those features were difficult individually.

The challenge appeared when all of them needed to coexist without turning the codebase into a collection of special cases.

The solution was never adding more conditions.

The solution was reducing responsibilities.

Every component gradually became smaller.

The platform became larger.

Ironically, those two things happened at the same time.

Engineering Means Preparing for Unknown Features

One question appeared repeatedly during development.

"Where should this feature go?"

At first the answer was almost always the same.

Inside the Trade Execution Engine.

Later the answer changed completely.

Instead of asking where code should be added, the better question became:

Which component should own this responsibility?

That small change in mindset prevented many future architectural mistakes.

A Position Manager should not execute orders.

A Risk Engine should not send API requests.

An Exchange Client should not evaluate trading policy.

Analytics should never decide whether a position should close.

Every component should be replaceable without rewriting the entire platform.

That principle sounds obvious.

It rarely remains obvious after months of continuous feature development.

Good architecture isn't created once.

It is protected continuously.

Future Evolution

The current platform already supports production-oriented trading features.

TradingView Webhooks.

Spot and Futures execution.

Partial Take Profit.

Break Even.

Trailing Stop.

Reverse Signals.

Persistent position storage.

Analytics.

Restart recovery.

WebSocket market data.

Telegram management.

Yet the architecture intentionally leaves room for future growth.

One possible direction is portfolio-level risk.

Today every position is evaluated independently.

A future version may evaluate the entire account before approving new trades.

                Current

 BTCUSDT ─────┐
 ETHUSDT ─────┤
 SOLUSDT ─────┤
              ▼
        Independent Risk


               Future

 BTCUSDT ─────┐
 ETHUSDT ─────┤
 SOLUSDT ─────┤
              ▼
 Portfolio Risk Engine
              │
 Exposure Limits
 Correlation Analysis
 Daily Loss Limits
 Sector Allocation

Another future improvement involves adaptive position sizing.

Today quantity is configured before trading begins.

A future Risk Engine could determine position size dynamically based on volatility, available capital or portfolio exposure.

Those improvements become possible because the architecture already separates execution from policy.

Replacing one Risk implementation should not require changing the execution pipeline.

That is exactly the flexibility modular systems are designed to provide.

Engineering Decisions That Changed the Platform

Several decisions fundamentally changed the direction of the project.

Not because they introduced new functionality.

Because they simplified everything that followed.

State became explicit.

Instead of reconstructing position state from exchange responses, the platform owns its own persistent state.

That made restart recovery and analytics straightforward.

Risk became continuous.

Instead of evaluating Stop Loss only when opening a trade, every market event became an opportunity to reassess exposure.

Risk transformed from a calculation into an ongoing process.

Components became independent.

Execution.

Risk.

Position Management.

Analytics.

Market Data.

Exchange Connectivity.

Each component now has a clearly defined responsibility.

That dramatically reduced coupling across the platform.

Events became the language of the platform.

Rather than allowing every module to call every other module directly, the system increasingly communicates through meaningful lifecycle events.

Position Opened.

TP1 Reached.

Break Even Activated.

Trailing Updated.

Position Closed.

Those events describe business activity instead of implementation details.

That distinction makes the architecture easier to evolve.

flowchart LR

Signal --> TradeEngine

TradeEngine --> Risk

Risk --> PositionManager

PositionManager --> Analytics

Risk --> Exchange

Exchange --> PositionManager

PositionManager --> Notifications

PositionManager --> Statistics

Analytics --> Reports

As the number of features increased, communication patterns actually became simpler.

That is usually a strong indication that an architecture is moving in the right direction.

Engineering Principle

One idea became increasingly clear throughout the development of this trading platform.

Risk management is not a function.

It is not a Stop Loss formula.

It is not a percentage.

It is not even a single component.

Risk management is a continuous conversation between market events, position state and business policy.

The execution engine should never decide whether a position is safe.

The Position Manager should never decide how an order is sent.

The Exchange Client should never decide when exposure should change.

Each component should answer one question exceptionally well.

Everything else belongs somewhere else.

That philosophy produced far cleaner code than any refactoring technique.

The best architecture wasn't created by adding abstractions.

It emerged by removing unnecessary responsibilities.

As the platform grew larger, individual components became easier to understand.

Paradoxically, that is often what healthy software evolution looks like.

What's Next

In the next chapter we'll move one layer higher.

So far we've focused on executing trades safely.

The next challenge is understanding performance over time.

We'll explore how the platform evolved from simple trade history into a production-ready analytics subsystem capable of measuring profitability, trading behavior, execution quality and long-term strategy performance.

Because opening profitable trades is only half the problem.

Understanding why they were profitable is what turns a trading bot into an engineering platform.

Learn More

This article covers only one part of the overall platform architecture.

If you'd like to explore the project, its features and follow future development, visit the project page:

Bybit Signal Trading Platform

https://py-dev.top/application-software/bybit-signal-trading-bot

There you'll find an overview of the platform, supported features and future updates.

SEO Keywords Covered

algorithmic trading
algorithmic trading platform
Python trading bot
Python trading architecture
production-ready trading system
production-ready risk management
trading risk engine
position manager
trade execution engine
TradingView webhook
Bybit API
WebSocket trading
futures trading
spot trading
event-driven architecture
software architecture
trading platform architecture
trading system design
risk evaluation
break even
trailing stop
reverse signal
engineering blog
backend engineering
Python backend
system design

Thank you for reading! If you enjoyed this engineering story, follow the series as we continue documenting the architectural evolution of a production-ready algorithmic trading platform built with Python.

Building a Production-Ready Position Manager for Algorithmic Trading

PyDev — Wed, 15 Jul 2026 16:35:57 +0000

Series: Engineering an Algorithmic Trading Platform in Python

Part: 3 of 18

About this series

This series documents the engineering evolution of a production-ready algorithmic trading platform in Python. It focuses on architecture, state management, execution, real-time data processing, persistence, and the failures that forced the system to improve.

In Part 2: Designing a Modular Trade Execution Engine in Python, I described the component responsible for turning validated signals into controlled exchange operations.

That engine could open a position.

The next problem was keeping it alive.

Introduction

The first version of our trading engine did not have a Position Manager.

It had variables.

That distinction sounds trivial.

It was not.

The Trade Execution Engine received a TradingView webhook, validated the signal, submitted a market order, and stored a few values in memory.

Then it waited for the next market price.

The architecture felt clean because the first dozen test trades behaved exactly as expected:

TradingView Signal
        │
        ▼
Trade Execution Engine
        │
        ▼
Exchange Order
        │
        ▼
Position Closed

Nothing appeared broken.

The illusion lasted until the platform needed to manage something more complicated than a single entry followed by a single exit.

Partial Take Profit arrived first.

Suddenly one position had two quantities:

the quantity already closed;
the quantity still exposed to the market.

Then Break Even appeared.

Then Trailing Stop.

Then reverse signals, Futures positions, leverage, restart recovery, Telegram controls, analytics, and multiple trading pairs.

None of those features were individually difficult.

The architecture was.

The problem was no longer order execution.

The problem was state.

This Position Manager eventually became one of the core components of my Python algorithmic trading platform, responsible for managing both Spot and Futures positions throughout their entire lifecycle.

The complete project is available here:

https://py-dev.top/application-software/bybit-signal-trading-bot

The goal of this article isn't to explain the entire platform, but rather to document one architectural decision that significantly improved its reliability and maintainability.

The Illusion of Simplicity

Almost every small trading system begins with something like this:

entry_price = 62_480.5
take_profit = 65_600.0
stop_loss = 61_200.0
qty = 0.001

For one position with one exit, these values are perfectly reasonable.

Then the feature set grows.

Partial Take Profit needs a remaining quantity:

remaining_qty = 0.001

Break Even needs another price and another transition flag:

breakeven_price = 62_480.5
tp1_hit = False

Trailing Stop needs the best market extreme observed since entry:

highest_price = None
lowest_price = 62_480.5
trailing_stop_price = None
trailing_active = False

Futures introduce market type, side, and leverage:

market = "futures"
side = "short"
leverage = 10

Restart recovery needs timestamps and persistent storage.

Analytics needs strategy, interval, signal source, order identifiers, fees, funding, and a close reason.

Eventually the application is carrying values like these through unrelated functions:

entry_price
qty
remaining_qty
tp1_hit
tp2_hit
highest_price
lowest_price
breakeven_price
trailing_stop_price
market
side
leverage
created_at
updated_at
...

Nothing connects them except convention.

Every function gains more parameters.

Every feature updates state in several places.

The code does not become more capable.

It becomes more fragile.

Common pitfall

A system can look modular at the class level while still sharing one large, implicit state model through loose variables.

The Real Problem Was State

A position is not a group of prices.

It is a business object with a history.

Once the platform became event-driven, nearly every subsystem depended on the same evolving position state:

signals opened positions;
WebSocket prices modified them;
Take Profit reduced them;
Break Even changed their risk profile;
Trailing Stop followed market extremes;
reverse signals closed them;
analytics interpreted their completed lifecycle;
Telegram displayed their current state;
persistence reconstructed them after restart.

Keeping this information scattered across variables was no longer viable.

The question changed from:

Which variables describe this trade?

to:

What is a position in this system?

That question produced the Position Manager.

State Belongs Together

Every active trade became one structured object.

Position
│
├── Symbol
├── Market
├── Side
├── Original Quantity
├── Remaining Quantity
├── Entry Price
├── TP1 Price
├── TP2 Price
├── Stop Loss Price
├── Break-Even Price
├── Trailing Stop Price
├── Highest Observed Price
├── Lowest Observed Price
├── TP1 State
├── TP2 State
├── Trailing State
├── Leverage
├── Strategy Metadata
├── Execution Identifiers
├── Created At
└── Updated At

A simplified persistent representation looks like this:

{
  "symbol": "BTCUSDT",
  "market": "futures",
  "side": "short",
  "entry_price": 62480.5,
  "qty": 0.001,
  "remaining_qty": 0.001,
  "tp1_price": 59356.475,
  "tp2_price": 56232.45,
  "stop_loss_price": 65604.525,
  "breakeven_price": 62480.5,
  "tp1_hit": false,
  "tp2_hit": false,
  "trailing_active": false,
  "highest_price": null,
  "lowest_price": 62480.5,
  "leverage": 10,
  "status": "open"
}

The Position Manager no longer remembers twenty unrelated values.

It remembers one position.

That object becomes the single source of truth for the active trade lifecycle.

The Position Manager Stopped Making Trading Decisions

A Position Manager can easily become a second Trade Execution Engine.

It starts validating signals.

Then it calculates indicators.

Then it decides whether to enter.

Then it calls the exchange.

Soon no one can explain which component owns which decision.

We moved in the opposite direction.

The Trade Execution Engine owns trading intent.

The Position Manager owns position state.

TradingView / Signal Engine
             │
             ▼
    Trade Execution Engine
             │
             ▼
       Position Manager
             │
             ▼
        State Changes

The Trade Execution Engine answers:

Is this action supported?
Is the pair enabled?
Is execution allowed in the current mode?
Should the action use Spot or Futures?
Which exchange operation should be called?

The Position Manager answers:

What position currently exists?
What changed after this price update?
How much quantity remains?
Which lifecycle transition is valid next?
What state must be persisted?

Engineering decision

The Trade Execution Engine decides. The Position Manager remembers.

That boundary became one of the most important separations in the platform.

Orders Are Events; Positions Are State

The distinction became obvious after the first partial exit.

Imagine one Futures short position:

An opening order creates the position.
TP1 closes part of it.
TP2 closes another part.
Trailing Stop closes the remainder.

How many positions existed?

One.

How many exchange orders existed?

Four.

Position
│
├── Open Order
├── TP1 Close Order
├── TP2 Close Order
└── Final Close Order

The position is the business object.

Orders are events that mutate it.

This also explains why exchange order history cannot replace application state. The exchange can report what executed, but it does not know:

why TP1 existed;
whether Break Even should activate afterward;
whether TP2 closes a percentage of the original quantity or the remainder;
when trailing is allowed to begin;
which strategy opened the trade;
what the next valid state transition should be.

The exchange remembers executions.

The application remembers intent.

Price Updates Became Events

Originally, every incoming WebSocket price executed trading logic directly.

That was manageable when the platform had one Take Profit and one Stop Loss.

It became difficult to reason about once TP1, TP2, Break Even, and Trailing Stop could all interact with the same position.

We stopped treating a price as an instruction.

A price became input to the current state.

The output became a domain event.

Live Price
    │
    ▼
Current Position State
    │
    ▼
Position Manager
    │
    ▼
Domain Event

A price update can produce an event such as:

{
  "action": "tp1_hit",
  "symbol": "BTCUSDT",
  "side": "short",
  "price": 62836.2,
  "close_qty": 0.002,
  "new_remaining_qty": 0.002,
  "new_stop_loss_price": 62712.0,
  "new_lowest_price": 62712.0
}

Or it can produce a trailing update:

{
  "action": "trailing_update",
  "symbol": "BTCUSDT",
  "new_trailing_stop_price": 63150.5,
  "new_lowest_price": 62500.0
}

Or a terminal event:

{
  "action": "stop_loss_hit",
  "symbol": "BTCUSDT",
  "close_reason": "stop_loss"
}

The Position Manager does not need to place the order itself.

It describes what changed.

The execution layer performs the exchange operation, while storage persists the confirmed state.

That distinction removed a surprising amount of coupling.

One Position Became Two Quantities

Closing an entire position is straightforward.

Partial closure is not.

Suppose the platform opens a position with:

Original Quantity: 0.004 BTC
Remaining Quantity: 0.004 BTC

TP1 closes half:

Closed at TP1:      0.002 BTC
Remaining Quantity: 0.002 BTC

The position is now simultaneously:

still open;
partially realized;
protected by a different Stop Loss;
eligible for later lifecycle transitions.

It cannot be represented accurately by a single is_open Boolean.

It has become a state machine.

stateDiagram-v2
    [*] --> Open
    Open --> TP1Hit
    TP1Hit --> BreakEvenActive
    BreakEvenActive --> TP2Hit
    TP2Hit --> TrailingActive
    TrailingActive --> Closed
    Open --> Closed: Stop Loss
    BreakEvenActive --> Closed: Break Even

Every transition evolves the same position object.

Nothing is deleted and recreated after TP1.

The original context remains available:

entry price;
original quantity;
remaining quantity;
strategy;
signal source;
risk settings;
execution history.

This is critical for correct analytics and restart recovery.

Remaining Quantity Became the Most Important Number

A partial exit changes future execution.

After TP1, TP2 must not close the original quantity again.

Trailing Stop must close only what remains.

Analytics must distinguish realized and unrealized portions.

The platform therefore updates remaining_qty after every confirmed partial close:

new_remaining_qty = max(
    0.0,
    position["remaining_qty"] - closed_qty,
)

storage.update_position(
    symbol,
    {
        "remaining_qty": new_remaining_qty,
        "updated_at": now(),
    },
)

The important detail is not the subtraction.

It is when the subtraction becomes authoritative.

The state should not be updated merely because the Position Manager predicted that TP1 had been reached. The execution operation must succeed first.

The real sequence is:

Price Reaches TP1
        │
        ▼
Position Manager Emits tp1_hit
        │
        ▼
Execution Layer Sends Partial Close
        │
        ▼
Exchange Confirms Operation
        │
        ▼
Persistent Position State Is Updated

Otherwise the local platform can believe quantity was closed when the exchange rejected the request.

Lesson learned

Predicted state and confirmed state are not the same thing.

Break Even Is Not Just a Price

Most descriptions of Break Even reduce it to one operation:

Move Stop Loss to the entry price.

The calculation is easy.

The state transition is not.

Before TP1, the position accepts a configured maximum loss.

After TP1, the platform enters a different risk state: part of the position has already been realized, and the remaining exposure should no longer be allowed to return to the original Stop Loss.

For a long position:

new_stop_loss_price = position["entry_price"]

For a short position, the numeric value may be the same, but the trigger direction is reversed.

The Position Manager therefore does not merely change a price.

It records that the lifecycle has advanced:

storage.update_position(
    symbol,
    {
        "tp1_hit": True,
        "remaining_qty": new_remaining_qty,
        "stop_loss_price": position["breakeven_price"],
        "updated_at": now(),
    },
)

That state is then used by every future price update.

Break Even is better understood as a risk transition:

Before TP1
    │
    └── Configured Loss Is Still Possible

After TP1
    │
    └── Remaining Exposure Is Protected at Entry

The difficult part was not calculating the Break-Even price.

The difficult part was ensuring the platform could activate it exactly once and remember that decision after a restart.

Why Trailing Stop Is Actually a State Machine

Trailing Stop is often described as a formula that follows price.

That is only the final calculation.

The harder questions are architectural:

When may trailing begin?
Which quantity is still eligible?
Which market extreme should be remembered?
Can an older WebSocket price move the stop backward?
What happens after restart?
Has TP2 already occurred?
Is this a long position or a short position?

For a long position, the platform tracks the highest observed price:

if price > position["highest_price"]:
    new_highest_price = price

For a short position, it tracks the lowest observed price:

if price < position["lowest_price"]:
    new_lowest_price = price

The trailing price is derived from that extreme, not from the current tick.

A short position might use:

new_trailing_stop_price = (
    new_lowest_price
    * (1 + trailing_percent / 100)
)

The important invariant is monotonic protection.

For a long position, the trailing stop must never move downward.

For a short position, it must never move upward.

Long Position
    Highest Price ↑
    Trailing Stop  ↑ or unchanged

Short Position
    Lowest Price   ↓
    Trailing Stop  ↓ or unchanged

This is why trailing belongs to the position lifecycle rather than the exchange adapter. It depends on historical state, transition eligibility, remaining quantity, and the direction of the position.

Persistent State Stopped Being Optional

During early testing, restarting the process cleared every in-memory position.

That was acceptable while trades were synthetic.

It stopped being acceptable once the exchange held real Testnet positions.

One evening, the VPS restarted after automatic updates.

Linux came back online.

The platform started normally.

The exchange still had open Futures positions.

The application had forgotten every one of them.

That was the moment persistence stopped being a useful feature.

It became an operational requirement.

Consider the failure sequence:

Position Opened
      │
      ▼
TP1 Executed
      │
      ▼
Stop Loss Moved to Break Even
      │
      ▼
Process Restarts
      │
      ▼
In-Memory State Is Lost

Without persistence, the platform no longer knows:

TP1 has already executed;
half the quantity is gone;
Stop Loss should remain at Break Even;
trailing may be eligible later;
the WebSocket subscription must be restored.

The exchange still has exposure, but the application has lost its strategy memory.

Every meaningful state transition therefore has to be persisted.

Not just position creation.

Not just final closure.

Every transition:

Open Position       → Save
TP1 Confirmed       → Save
Break Even Applied  → Save
TP2 Confirmed       → Save
Trailing Updated    → Save
Position Closed     → Archive

Engineering decision

If losing a value changes future trading behaviour, that value belongs in persistent storage.

Recovery Is Reconstructing Behaviour, Not Reloading JSON

Loading a position file after startup is easy.

Restoring the platform is harder.

A recovered position must become operational again.

The restart flow looks like this:

Application Starts
        │
        ▼
Load Open Positions
        │
        ▼
Validate Stored State
        │
        ▼
Restore WebSocket Subscriptions
        │
        ▼
Resume Price Processing
        │
        ▼
Continue from the Last Confirmed Lifecycle State

The system must not replay TP1 if tp1_hit is already true.

It must not reset remaining_qty to the original quantity.

It must not discard the remembered highest or lowest price.

It must not activate trailing before its prerequisites are satisfied.

Recovery means reconstructing the same behaviour that existed before the process stopped.

That is a much stricter requirement than simply reading stored data.

Position Ownership Became Explicit

As the platform grew, more components needed access to position information:

the Trade Execution Engine;
WebSocket processing;
persistent storage;
analytics;
Telegram reporting.

Allowing every component to mutate positions directly would create an ownership problem.

We introduced a simple rule:

Every position mutation flows through one controlled path.

                 +------------------------+
                 | Trade Execution Engine |
                 +-----------+------------+
                             |
                             v
                 +------------------------+
                 |    Position Manager    |
                 +-----------+------------+
                             |
             +---------------+----------------+
             |               |                |
             v               v                v
       Persistence      WebSocket State    Analytics Input

Storage writes remain explicit.

WebSocket callbacks provide prices but do not invent lifecycle transitions.

Analytics reads completed state but does not modify active positions.

Telegram displays state and triggers commands through the normal execution path.

This ownership rule eliminated an entire class of synchronization problems.

When a position changes, there is one place to investigate.

What the Position Manager Does Not Do

Defining exclusions was as important as defining responsibilities.

The Position Manager does not:

generate TradingView signals;
calculate EMA, RSI, or MACD;
validate webhook secrets;
choose Dry Run, Testnet, or Mainnet clients;
format Telegram reports;
calculate monthly trading statistics;
communicate directly with every exchange endpoint.

It receives position state and a price.

It returns a state transition.

Conceptually, its core API is small:

result = position_manager.on_price_update(
    position=position,
    price=current_price,
)

The result is declarative:

{
    "action": "tp1_hit",
    "close_qty": 0.002,
    "new_remaining_qty": 0.002,
    "new_stop_loss_price": 62712.0,
}

This makes the component easier to test.

A unit test does not need TradingView, Telegram, or a live Bybit connection. It only needs a position and a sequence of prices.

The First Useful Tests Were State-Transition Tests

Traditional exchange integration tests answer questions such as:

Was the request authenticated?
Did the exchange accept the order?
Was an order ID returned?

Position Manager tests answer different questions:

Does TP1 execute only once?
Is the correct partial quantity returned?
Does Break Even activate after TP1?
Does a short position track the lowest price?
Can trailing protection ever move backward?
Does Stop Loss close only the remaining quantity?
Does restart recovery preserve lifecycle flags?

A simplified test can replay a price sequence:

position = make_short_position(
    entry_price=64_000.0,
    qty=0.004,
    tp1_price=62_000.0,
)

result = manager.on_price_update(position, 61_900.0)

assert result["action"] == "tp1_hit"
assert result["close_qty"] == 0.002
assert result["new_remaining_qty"] == 0.002
assert result["new_stop_loss_price"] == 64_000.0

The important part is determinism.

The same position and the same price should always produce the same transition.

That property is far easier to preserve when the Position Manager does not perform network operations.

Looking Back

The Position Manager was not part of the original design.

It was extracted from repeated failures of the simpler model.

Partial exits exposed the limits of independent variables.

Break Even exposed hidden coupling between execution and risk state.

Trailing Stop exposed the need to preserve market history.

Restart recovery exposed the danger of in-memory ownership.

Analytics exposed inconsistent quantity tracking.

None of those failures required a more complicated trading strategy.

They required a more explicit state model.

Looking back, the biggest mistake was not writing poor code.

It was believing that no Position Manager was necessary.

That belief remained reasonable only while the platform managed one trivial lifecycle.

The moment a position could evolve, persistence and ownership became architectural concerns.

Lessons Learned

A production-ready Position Manager is not a container for open orders.

It is the system's memory of an active strategy.

The most important lessons were:

an order and a position are different domain objects;
partial exits require original and remaining quantity;
price updates should produce explicit domain events;
Break Even is a lifecycle transition, not only a number;
Trailing Stop depends on historical state and monotonic invariants;
predicted transitions must not be confused with confirmed execution;
every behaviour-changing state update must be persistent;
restart recovery must restore behaviour, not merely data;
one component must own position mutation;
a deterministic Position Manager is significantly easier to test.

The exchange can tell us that an order executed.

It cannot tell us what that execution means to the strategy.

That responsibility belongs to the platform.

Engineering Principle

A position is not an order. It's the memory of your trading strategy.

What's Next

The Position Manager described in this article is just one component of a larger algorithmic trading platform that I've been building over the past several months.

If you're curious about the overall architecture and how these components fit together, you can learn more about the project here:

https://py-dev.top/application-software/bybit-signal-trading-bot

Throughout this series, I'm documenting the engineering decisions that shaped the platform rather than publishing its complete source code.

The next chapter continues this architectural evolution by introducing the Risk Management Engine—the component responsible for transforming position state into real-time risk decisions.

We'll explore how a production-ready Risk Management Engine coordinates:

Stop Loss
Position limits
Partial Take Profit
Break Even
Trailing Stop
Reverse Signals
Leverage
Emergency Close
Spot and Futures risk management
Dry Run, Testnet, and Mainnet safeguards

👉 Next article:
Building a Production-Ready Risk Management Engine for Algorithmic Trading

https://dev.to/pydevtop/building-a-production-ready-risk-management-engine-for-algorithmic-trading-1jh8

Designing a Modular Trade Execution Engine in Python

PyDev — Wed, 15 Jul 2026 12:54:42 +0000

Series: Engineering an Algorithmic Trading Platform in Python

Part: 2 of 18

About this series

This series documents the engineering decisions behind building a production-ready algorithmic trading platform in Python. The focus is not on trading strategies or profit claims. It is on software architecture, trade execution, state management, real-time data processing, and system reliability.

Introduction

In the first article, I described how a simple TradingView webhook project gradually evolved into a modular algorithmic trading platform.

The first version was straightforward:

TradingView
      │
      ▼
FastAPI Webhook
      │
      ▼
Bybit API

A signal arrived, Python parsed the payload, and the application submitted an order.

That flow was enough to prove that the integration worked.

It was not enough to build reliable trading software.

As soon as the platform needed to support Spot orders, Futures short positions, reverse signals, disabled pairs, position limits, restart recovery, partial exits, and multiple signal sources, one component became unavoidable:

the Trade Execution Engine

The Trade Execution Engine is the layer that converts external intent into controlled trading actions.

It receives normalized signals from TradingView or a local Python signal engine, checks the current system state, validates the request against configuration, decides whether execution is allowed, and routes the action to the correct exchange method.

That sounds simple when written as one sentence.

In practice, this layer becomes the boundary between untrusted external input and real exchange activity.

A mistake here does not produce a broken page or a failed background job.

It can open the wrong market, use the wrong position side, execute the same signal twice, or create a position that the rest of the platform cannot manage correctly.

This article explores the architecture of a modular Python Trade Execution Engine, including:

signal normalization;
action routing;
pair configuration;
Spot and Futures separation;
state-aware decisions;
reverse signals;
duplicate protection;
order execution flow;
error boundaries;
persistent position state;
Dry Run, Testnet, and Mainnet modes;
trade-offs discovered during development.

The examples are based on a real Python algorithmic trading platform built with FastAPI, TradingView webhooks, the Bybit API, WebSockets, SQLite analytics, and Telegram control.

What the Trade Execution Engine Actually Does

The name can be misleading.

A Trade Execution Engine should not be one large function that contains the complete trading platform.

It should not:

calculate EMA, RSI, or MACD;
receive raw HTTP requests;
maintain Telegram menus;
calculate monthly trading analytics;
subscribe directly to every WebSocket stream;
format user notifications;
contain exchange credentials;
store unrelated application settings.

Its responsibility is narrower:

Accept a validated trading signal, evaluate whether the action is allowed, dispatch the correct execution request, and synchronize the resulting position state.

A simplified flow looks like this:

Normalized Signal
       │
       ▼
Trade Execution Engine
       │
       ├── Validate symbol
       ├── Validate action
       ├── Load pair configuration
       ├── Check enabled state
       ├── Check execution mode
       ├── Inspect open positions
       ├── Apply signal rules
       └── Dispatch execution
                 │
                 ▼
        Exchange Client
                 │
                 ▼
        Position Manager
                 │
                 ▼
          Persistent State

This boundary is important because signals and orders are not the same thing.

A signal expresses intent:

{
  "symbol": "BTCUSDT",
  "action": "SELL_FUTURES",
  "price": 62480.5
}

An exchange order requires operational details:

{
  "category": "linear",
  "symbol": "BTCUSDT",
  "side": "Sell",
  "orderType": "Market",
  "qty": "0.001"
}

The Trade Execution Engine is responsible for translating one into the other without allowing infrastructure details to leak into signal sources.

Engineering decision

TradingView should describe what the strategy wants to do. It should not need to know how the exchange API expects that action to be executed.

Why the Webhook Should Not Contain Trading Logic

It is tempting to process everything directly inside the FastAPI route.

A minimal example often looks like this:

@app.post("/webhook")
def webhook(payload: dict):
    if payload["action"] == "BUY":
        bybit.place_spot_buy(
            symbol=payload["symbol"],
            qty=payload["qty"],
        )

    return {"ok": True}

This works until the application needs any real rules.

For example:

the pair may be disabled;
the signal may use an unsupported action;
another position may already be open;
the same webhook may arrive twice;
the platform may be in Dry Run mode;
Spot buying may be disabled while Futures trading remains enabled;
the symbol may not exist in the local order configuration;
a reverse signal may require closing one position before opening another;
the exchange may accept the order but return incomplete execution data;
position state may fail to persist after the order succeeds.

If all of those checks live inside the webhook endpoint, the API layer becomes tightly coupled to trading behaviour.

That creates several problems.

It becomes difficult to test

Testing an HTTP route should not require a live exchange client.

It becomes difficult to reuse

A local Python signal engine cannot reuse webhook-only logic cleanly.

It becomes difficult to control

Telegram actions, TradingView webhooks, and internal signals start following different execution paths.

It becomes difficult to recover

If order execution and persistence fail at different stages, there is no single component responsible for resolving the inconsistency.

A cleaner webhook endpoint only validates and forwards the request.

from fastapi import FastAPI, HTTPException

app = FastAPI()

@app.post("/webhook")
def webhook(payload: dict):
    if payload.get("secret") != settings.webhook_secret:
        raise HTTPException(status_code=403, detail="Invalid secret")

    signal = {
        "symbol": str(payload.get("symbol", "")).upper(),
        "action": str(payload.get("action", "")).upper(),
        "price": float(payload.get("price", 0)),
        "source": "tradingview",
    }

    return trade_engine.process_signal(signal)

The HTTP layer remains stateless.

The Trade Execution Engine owns the trading decision.

Designing a Stable Signal Contract

Before the engine can route anything, it needs a stable signal format.

Different signal sources often produce different payloads.

TradingView may send:

{
  "secret": "test123",
  "strategy": "ema-cross",
  "exchange": "BYBIT",
  "symbol": "BTCUSDT",
  "interval": "15",
  "price": "62480.5",
  "time": "2026-07-15T10:30:00Z",
  "action": "SELL_FUTURES"
}

A local signal engine may produce:

{
    "symbol": "BTCUSDT",
    "action": "SELL_FUTURES",
    "price": 62480.5,
    "strategy": "ema_rsi_macd",
    "interval": "15",
    "source": "pydev_signal_engine",
}

A Telegram emergency action may not have a market price at all:

{
    "symbol": "BTCUSDT",
    "action": "CLOSE_ALL",
    "source": "telegram",
}

If every source uses a different internal representation, the engine becomes full of special cases.

The solution is signal normalization.

from typing import Any

SUPPORTED_ACTIONS = {
    "BUY_SPOT",
    "SELL_FUTURES",
    "CLOSE_ALL",
}

def normalize_signal(payload: dict[str, Any]) -> dict[str, Any]:
    symbol = str(payload.get("symbol", "")).strip().upper()
    action = str(payload.get("action", "")).strip().upper()

    price_raw = payload.get("price")
    price = float(price_raw) if price_raw not in (None, "") else None

    return {
        "symbol": symbol,
        "action": action,
        "price": price,
        "strategy": payload.get("strategy"),
        "interval": str(payload.get("interval", "")),
        "source": payload.get("source", "unknown"),
        "signal_id": payload.get("signal_id"),
        "received_at": payload.get("received_at"),
    }

Every source is converted into the same contract before reaching the Trade Execution Engine.

That gives the engine a predictable input.

Key takeaway

A stable internal signal contract is more important than the original payload format. External integrations can change without forcing the core engine to change with them.

Explicit Trading Actions Are Better Than Ambiguous BUY and SELL

Generic BUY and SELL actions are often insufficient when one platform manages both Spot and Futures.

Consider the word SELL.

It may mean:

sell an existing Spot balance;
open a Futures short position;
close a Futures long position;
reduce a short position;
close the entire position;
execute a partial take profit.

Those are completely different operations.

For this reason, the platform uses explicit actions:

BUY_SPOT
SELL_FUTURES
CLOSE_ALL

The same principle can be extended later with actions such as:

SELL_SPOT
BUY_FUTURES
CLOSE_SPOT
CLOSE_FUTURES
REDUCE_POSITION

The exact action set depends on platform scope.

The important part is that the command should describe intent clearly enough that the engine does not need to guess.

A basic validation step looks like this:

def validate_action(action: str) -> tuple[bool, str | None]:
    allowed = {
        "BUY_SPOT",
        "SELL_FUTURES",
        "CLOSE_ALL",
    }

    if action not in allowed:
        return False, f"unsupported_action_{action}"

    return True, None

This makes logs and analytics easier to interpret.

unsupported_action_SELL

is much more useful than silently executing the wrong operation.

Loading Pair Configuration

The Trade Execution Engine should not hardcode trading amounts, leverage, take-profit settings, or pair permissions.

Those values belong in pair configuration.

A simplified orders.ini section may look like this:

[BTCUSDT]
bybit_pair = BTCUSDT
enabled = True
spot_amount = 100.0
futures_qty = 0.001
take_profit_1_percent = 5.0
take_profit_2_percent = 10.0
stop_loss_percent = 5.0
close_percent_on_tp1 = 50.0
close_percent_on_tp2 = 50.0
move_sl_to_breakeven = True
trailing_percent = 3.0
allow_spot_buy = True
allow_futures_short = True
max_open_positions = 1
leverage = 10

The engine receives only the symbol.

It loads everything else from the platform configuration.

def get_order_by_symbol(self, symbol: str) -> dict | None:
    for section_name, order in self.orders.items():
        if order.get("bybit_pair", "").upper() == symbol:
            return order

    return None

This creates a clean separation:

Signal Source
    │
    └── symbol + action

Trade Execution Engine
    │
    └── configuration lookup

Execution Layer
    │
    └── exchange-specific parameters

The signal source does not control leverage or quantity unless the system explicitly allows it.

That is a safer default for automated trading infrastructure.

Rejecting Unknown and Disabled Pairs

A production engine should fail closed.

If a symbol is not configured, it should not improvise.

order_config = self.get_order_by_symbol(symbol)

if not order_config:
    print(f"[REJECT] Pair not found in orders.ini: {symbol}")

    return {
        "ok": False,
        "reason": "pair_not_found",
        "symbol": symbol,
    }

The same applies to disabled pairs.

if not order_config.get("enabled", False):
    print(f"[REJECT] Pair disabled: {symbol}")

    return {
        "ok": False,
        "reason": "pair_disabled",
        "symbol": symbol,
    }

This may look like a small detail, but it prevents an external strategy from activating symbols that the platform operator did not approve.

The configuration is the authority.

The signal is only a request.

Common pitfall

Treating every valid-looking webhook as permission to trade. A syntactically valid signal can still violate local configuration and risk rules.

Separating Spot and Futures Execution

Spot and Futures orders may look similar at first.

Both submit market orders.

Both use a symbol and quantity.

Both return an exchange order ID.

But their semantics are different.

Spot BUY

A Spot buy typically:

spends quote currency;
acquires base currency;
does not use leverage;
cannot normally create a negative asset balance;
may use quote amount or base quantity depending on API parameters.

A Bybit Spot market buy can be represented like this:

result = session.place_order(
    category="spot",
    symbol=symbol,
    side="Buy",
    orderType="Market",
    marketUnit="BaseCoin",
    qty=str(qty),
)

Futures short

A Futures short typically:

opens a derivative position;
uses leverage;
has liquidation risk;
can incur funding;
requires reduce-only logic when closing;
must distinguish between opening and closing sides.

A Bybit linear Futures short can be represented like this:

result = session.place_order(
    category="linear",
    symbol=symbol,
    side="Sell",
    orderType="Market",
    qty=str(qty),
)

Using one generic place_order() call for both markets can hide important differences.

The engine should route them explicitly.

if action == "BUY_SPOT":
    return self._execute_spot_buy(
        symbol=symbol,
        order_config=order_config,
        signal=signal,
    )

if action == "SELL_FUTURES":
    return self._execute_futures_short(
        symbol=symbol,
        order_config=order_config,
        signal=signal,
    )

This keeps market-specific rules isolated.

A Practical `process_signal()` Structure

The public engine method should remain readable.

It should describe the execution pipeline without containing every implementation detail.

def process_signal(self, signal: dict) -> dict:
    symbol = str(signal.get("symbol", "")).upper()
    action = str(signal.get("action", "")).upper()

    print(f"[TRADE ENGINE] signal={signal}")

    if not symbol and action != "CLOSE_ALL":
        return {
            "ok": False,
            "reason": "empty_symbol",
        }

    if action not in {
        "BUY_SPOT",
        "SELL_FUTURES",
        "CLOSE_ALL",
    }:
        return {
            "ok": False,
            "reason": f"unsupported_action_{action}",
        }

    if action == "CLOSE_ALL":
        return self.close_all_positions(
            source=signal.get("source", "unknown"),
        )

    order_config = self.get_order_by_symbol(symbol)

    if not order_config:
        return {
            "ok": False,
            "reason": "pair_not_found",
            "symbol": symbol,
        }

    if not order_config.get("enabled", False):
        return {
            "ok": False,
            "reason": "pair_disabled",
            "symbol": symbol,
        }

    if action == "BUY_SPOT":
        return self._handle_spot_buy(
            signal=signal,
            order_config=order_config,
        )

    return self._handle_futures_short(
        signal=signal,
        order_config=order_config,
    )

This method acts as an orchestration layer.

It does not need to know every exchange parameter or every persistence field.

Those details belong in smaller components.

State Awareness Before Execution

A trading action should never be evaluated in isolation.

The engine needs to inspect current platform state.

Suppose SELL_FUTURES arrives for BTCUSDT.

The correct response depends on what already exists.

No open position

The engine may open a new short.

Existing short position

The engine may reject the duplicate, ignore it, or add to the position depending on platform policy.

Existing Spot position

The engine may allow both positions, or it may treat the signal as a reverse action.

Position already closing

The engine should avoid starting another conflicting transition.

Pair disabled after the signal was generated

The engine should reject the action.

This is why persistent position state is not just an analytics feature.

It is part of execution safety.

A simplified check may look like this:

position = storage.get_open_position(symbol)

if position:
    current_side = position.get("side")
    current_market = position.get("market")

    if action == "SELL_FUTURES":
        if current_market == "futures" and current_side == "short":
            return {
                "ok": False,
                "reason": "short_position_already_open",
                "symbol": symbol,
            }

The exact policy may differ between strategies.

What matters is that it is explicit.

Reverse Signals Need a Defined State Transition

Reverse signals are more complicated than they appear.

A naive implementation might do this:

if signal == "SELL":
    close_buy()
    open_short()

But several questions remain.

Was the first position fully closed?
Was it partially filled?
Did the close request fail?
Is the remaining quantity zero?
Should the new position open immediately?
Should the engine wait for exchange confirmation?
What happens if a second reverse signal arrives during the transition?

A safer model treats reversal as two separate state transitions.

OPEN SPOT POSITION
        │
        ▼
REVERSE SIGNAL RECEIVED
        │
        ▼
CLOSE CURRENT POSITION
        │
        ▼
VERIFY CLOSED STATE
        │
        ▼
OPEN FUTURES SHORT

The second action should not occur until the first one is confirmed.

A high-level implementation may look like this:

def handle_reverse_signal(
    self,
    symbol: str,
    target_action: str,
    signal: dict,
) -> dict:
    close_result = self.close_position(
        symbol=symbol,
        reason="reverse_signal",
    )

    if not close_result.get("ok"):
        return {
            "ok": False,
            "reason": "reverse_close_failed",
            "details": close_result,
        }

    if target_action == "SELL_FUTURES":
        return self._handle_futures_short(
            signal=signal,
            order_config=self.get_order_by_symbol(symbol),
        )

    return {
        "ok": False,
        "reason": "unsupported_reverse_target",
    }

In a more advanced implementation, the engine may wait for execution confirmation before opening the opposite position.

That avoids overlapping exposure.

Engineering note

A reverse signal is not one order. It is a coordinated workflow with at least two exchange operations and one persistent state transition.

Duplicate Signal Protection

Duplicate signals are an important risk in webhook-driven trading systems.

Duplicates can happen because of:

TradingView alert configuration;
webhook retries;
network timeouts;
manual resubmission;
strategy bugs;
multiple signal sources producing the same action;
application restart during request processing.

There are several ways to handle this.

Signal ID

The best option is a unique identifier generated by the source.

{
  "signal_id": "ema-cross-BTCUSDT-15m-20260715T103000Z",
  "symbol": "BTCUSDT",
  "action": "SELL_FUTURES"
}

The engine stores processed IDs.

if storage.signal_exists(signal_id):
    return {
        "ok": False,
        "reason": "duplicate_signal",
        "signal_id": signal_id,
    }

Time-window fingerprint

When the source cannot provide a unique ID, the platform can derive a fingerprint.

import hashlib
import json

def build_signal_fingerprint(signal: dict) -> str:
    payload = {
        "symbol": signal.get("symbol"),
        "action": signal.get("action"),
        "strategy": signal.get("strategy"),
        "interval": signal.get("interval"),
        "time": signal.get("time"),
    }

    encoded = json.dumps(
        payload,
        sort_keys=True,
        separators=(",", ":"),
    ).encode("utf-8")

    return hashlib.sha256(encoded).hexdigest()

The fingerprint can be stored with a short expiration window.

State-based rejection

Even without a signal ID, current position state may reject repeated actions.

For example, if a short is already open, another identical SELL_FUTURES signal can be ignored.

State-based protection is useful, but it is not a complete substitute for idempotency.

Two duplicate requests can arrive close enough together that both inspect the state before either one persists the new position.

That creates a race condition.

Idempotency and Race Conditions

This is where duplicate protection becomes a concurrency problem.

Consider two identical webhook requests:

Request A                 Request B
    │                         │
    ▼                         ▼
Check position           Check position
No position              No position
    │                         │
    ▼                         ▼
Place short              Place short

Both requests passed validation.

Both saw the same state.

Both submitted an order.

The result is double exposure.

A reliable implementation needs an atomic boundary around the critical section.

For a single-process platform, a per-symbol lock may be enough.

from collections import defaultdict
from threading import Lock

class SymbolLockRegistry:
    def __init__(self) -> None:
        self._locks: dict[str, Lock] = defaultdict(Lock)

    def get(self, symbol: str) -> Lock:
        return self._locks[symbol]

Then:

lock = self.symbol_locks.get(symbol)

with lock:
    position = storage.get_open_position(symbol)

    if position:
        return {
            "ok": False,
            "reason": "position_already_open",
        }

    return self._execute_futures_short(
        symbol=symbol,
        order_config=order_config,
        signal=signal,
    )

For a distributed architecture with multiple workers, an in-memory lock is not enough.

The platform would need a database transaction, distributed lock, queue partitioning, or another atomic coordination mechanism.

The current platform is self-hosted and single-user, so the simpler approach is appropriate.

That may change if the architecture becomes multi-worker or multi-user.

Trade-off

The simplest concurrency model that matches the deployment environment is usually better than adding distributed infrastructure prematurely.

Execution Modes: Dry Run, Testnet, and Mainnet

A Trade Execution Engine should not assume every validated signal must reach a live exchange account.

The platform supports three operational modes.

Dry Run

No exchange order is sent.

The engine simulates execution and creates internal position state.

This is useful for:

testing signal routing;
validating risk logic;
testing Telegram workflows;
testing analytics;
reproducing state transitions safely.

Testnet

The engine submits real API requests to the exchange test environment.

This validates:

API authentication;
order parameters;
exchange responses;
execution IDs;
WebSocket subscriptions;
position lifecycle logic.

Mainnet

The engine submits live orders.

This mode should require explicit configuration and clear UI status.

A clean execution abstraction may look like this:

def execute_order(self, request: dict) -> dict:
    if self.mode == "dry_run":
        return self.dry_run_executor.execute(request)

    if self.mode == "testnet":
        return self.testnet_client.execute(request)

    if self.mode == "mainnet":
        return self.mainnet_client.execute(request)

    return {
        "ok": False,
        "reason": f"unsupported_mode_{self.mode}",
    }

The Trade Execution Engine should not duplicate all logic three times.

Only the final execution adapter should change.

Order Execution and Position Persistence

Submitting the order is not the final step.

The platform must also create persistent position state.

A simplified Futures position record may contain:

{
  "symbol": "BTCUSDT",
  "market": "futures",
  "side": "short",
  "entry_price": 62480.5,
  "qty": 0.001,
  "remaining_qty": 0.001,
  "tp1_price": 59356.475,
  "tp2_price": 56232.45,
  "stop_loss_price": 65604.525,
  "breakeven_price": 62480.5,
  "tp1_hit": false,
  "tp2_hit": false,
  "trailing_active": false,
  "leverage": 10,
  "strategy": "ema_rsi_macd",
  "interval": "15",
  "signal_source": "tradingview",
  "open_order_id": "123456789",
  "status": "open",
  "mode": "testnet",
  "created_at": "2026-07-15T10:30:00Z"
}

This state is later used by:

the Position Manager;
the WebSocket price handler;
take-profit logic;
stop-loss logic;
restart recovery;
Telegram reports;
analytics after closure.

The execution flow becomes:

Signal accepted
      │
      ▼
Order request built
      │
      ▼
Exchange order submitted
      │
      ▼
Execution response validated
      │
      ▼
Position state created
      │
      ▼
WebSocket subscription activated
      │
      ▼
Telegram status updated

A failure at any stage must be visible.

Silently accepting an exchange order without storing the position is dangerous.

The exchange now has exposure, but the local platform may not know it exists.

Handling Exchange Errors

Exchange APIs fail in many ways.

Examples include:

invalid quantity precision;
insufficient balance;
unsupported symbol;
authentication errors;
rate limits;
temporary network failures;
rejected leverage settings;
market restrictions;
malformed API responses.

The engine should not convert every exception into a generic failure.

Structured errors make debugging easier.

try:
    result = self.bybit_client.open_futures_short(
        symbol=symbol,
        qty=qty,
    )
except TimeoutError as exc:
    return {
        "ok": False,
        "reason": "exchange_timeout",
        "symbol": symbol,
        "error": str(exc),
    }
except ValueError as exc:
    return {
        "ok": False,
        "reason": "invalid_order_parameters",
        "symbol": symbol,
        "error": str(exc),
    }
except Exception as exc:
    return {
        "ok": False,
        "reason": "exchange_execution_error",
        "symbol": symbol,
        "error": str(exc),
    }

The external API response should remain safe.

Sensitive credentials, signatures, and internal exception details should never be returned to TradingView.

Detailed errors can still be written to logs or sent to the operator through Telegram.

Do Not Trust the Requested Price as the Entry Price

TradingView may send a price with the signal.

That price is useful for context.

It is not necessarily the actual fill price.

Between signal generation and exchange execution:

the market can move;
the webhook can be delayed;
the order can slip;
the order can fill at multiple prices.

Therefore, the final position should use exchange execution data whenever possible.

signal_price = signal.get("price")
execution_price = result.get("avg_price")

entry_price = execution_price or signal_price

The fallback is useful in Dry Run mode or when the exchange response does not immediately provide an average fill price.

For live analytics, exchange execution data should remain the source of truth.

Lesson learned

Strategy price, requested price, order price, and execution price are not always the same value.

Keeping the Engine Independent from Analytics

It is tempting to calculate fees, ROI, and PnL directly after every order.

That creates tight coupling.

The Trade Execution Engine should record execution facts.

The Analytics Engine should calculate historical metrics.

For example, the execution layer may store:

{
  "symbol": "BTCUSDT",
  "order_id": "123456789",
  "side": "Sell",
  "market": "futures",
  "qty": 0.001,
  "price": 62480.5,
  "fee": 0.0312,
  "timestamp": "2026-07-15T10:30:02Z"
}

Later, analytics can calculate:

gross PnL;
net PnL;
ROI;
trading fees;
funding;
win rate;
average holding time;
monthly profit;
pair statistics.

This separation prevents reporting changes from affecting order execution.

Keeping Telegram Outside the Core Engine

Telegram is an operational control panel.

It can:

show open positions;
enable or disable pairs;
display analytics;
change signal engine settings;
trigger emergency close;
display current execution mode.

But Telegram handlers should not duplicate execution logic.

A Telegram action should call the same engine used by TradingView.

signal = {
    "symbol": selected_symbol,
    "action": "CLOSE_ALL",
    "source": "telegram",
}

result = trade_engine.process_signal(signal)

That produces one execution path:

TradingView ─┐
             ├──► Trade Execution Engine
Signal Engine┤
             │
Telegram ────┘

One engine.

One set of rules.

One state model.

That consistency becomes increasingly valuable as the platform grows.

Logging the Execution Pipeline

A good execution log should answer:

what signal arrived;
where it came from;
why it was accepted or rejected;
what order was submitted;
what exchange response was returned;
what position state was created;
which execution mode was active.

A practical log flow might look like this:

[TRADE ENGINE] signal={
  'symbol': 'BTCUSDT',
  'action': 'SELL_FUTURES',
  'source': 'tradingview'
}

[TRADE ENGINE] pair enabled: BTCUSDT
[TRADE ENGINE] execution mode: testnet
[TRADE ENGINE] opening futures short qty=0.001
[BYBIT FUTURES SHORT] order_id=123456789
[POSITION MANAGER] position created: BTCUSDT short
[WEBSOCKET] subscribed: tickers.BTCUSDT

Rejection logs should be equally clear.

[REJECT] Pair disabled: ETHUSDT

or:

[REJECT] Short position already open: BTCUSDT

Readable logs are part of system design, not an afterthought.

A More Complete Execution Flow

The complete flow can now be represented like this:

TradingView / Signal Engine / Telegram
                  │
                  ▼
          Signal Normalization
                  │
                  ▼
          Action Validation
                  │
                  ▼
        Pair Configuration Lookup
                  │
                  ▼
          Enabled / Permission Check
                  │
                  ▼
            Duplicate Check
                  │
                  ▼
          Current State Inspection
                  │
                  ▼
             Symbol Lock
                  │
                  ▼
       Spot / Futures Route Selection
                  │
                  ▼
          Exchange Request Builder
                  │
                  ▼
      Dry Run / Testnet / Mainnet Adapter
                  │
                  ▼
          Exchange Result Validation
                  │
                  ▼
          Persistent Position State
                  │
                  ▼
         WebSocket Subscription Update
                  │
                  ▼
         Telegram / Logging / Analytics

This architecture is more complex than calling place_order() directly.

That complexity is intentional.

Every layer exists because a real failure mode appeared or became predictable during development.

What Belongs in the Trade Execution Engine

A useful rule is to classify responsibilities by question.

Does this signal describe a supported action?

Trade Execution Engine.

Is this pair allowed to trade?

Trade Execution Engine and configuration.

Is a position already open?

Trade Execution Engine and Position Storage.

How is a Bybit Futures short submitted?

Exchange Client.

Has TP1 been reached?

Position Manager.

What is the current BTCUSDT price?

WebSocket Manager.

What is the monthly net profit?

Analytics Service.

Should the operator receive a notification?

Telegram or Notification Service.

This separation keeps the engine small enough to reason about.

Current Trade Execution Features

At the current stage, the platform execution pipeline supports:

TradingView webhook signals;
local Python signal generation;
explicit Spot BUY actions;
explicit Futures SHORT actions;
emergency close operations;
pair-level enable and disable controls;
pair-specific quantity and risk settings;
Dry Run execution;
Bybit Testnet execution;
Bybit Mainnet execution mode;
persistent position state;
restart recovery;
dynamic WebSocket subscriptions;
reverse signal handling;
rejection of unsupported signals;
rejection of missing or disabled pairs;
structured execution results;
Telegram control integration;
SQLite-based trade analytics after closure.

Some areas continue to evolve, especially duplicate signal idempotency, exchange execution reconciliation, and more advanced handling of partial fills.

That is expected.

Production trading software is not finished when the first order succeeds.

It becomes reliable through repeated testing against failure cases.

Engineering Challenges That Appear Next

Once the Trade Execution Engine is stable, the next layer becomes the position lifecycle.

Opening a position is only the beginning.

The platform still needs to answer:

When is TP1 reached?
How much quantity should close?
Should Stop Loss move to Break Even?
When should trailing become active?
How are highest and lowest prices tracked?
How should partial exits be stored?
What happens after a restart?
How does the system close the remaining quantity safely?
How are Spot and Futures lifecycle rules kept separate?

Those responsibilities belong to the Position Manager.

The Trade Execution Engine creates the position.

The Position Manager keeps it alive.

Conclusion

Building a Trade Execution Engine changed the project more than any individual trading feature.

Before this layer existed, signals were too closely connected to exchange calls.

After introducing it, every signal source could use the same execution path.

TradingView, Telegram, and the local Python signal engine no longer needed to understand Bybit order parameters.

They only needed to express intent.

The engine became responsible for the difficult boundary between intent and execution:

validating actions;
loading configuration;
inspecting state;
preventing invalid transitions;
routing Spot and Futures operations;
coordinating reverse signals;
controlling execution modes;
persisting position state;
reporting structured results.

The most important lesson was simple:

Reliable trading software is not built around the ability to place orders. It is built around the ability to control when an order is allowed, understand what state it creates, and recover when something goes wrong.

The platform described in this series continues to evolve. A technical overview of the current project is available here:

https://py-dev.top/application-software/bybit-signal-trading-bot

The link is included for readers who want to see the broader system context. The purpose of this series remains engineering: architecture, implementation decisions, failure modes, and lessons learned while building automated trading infrastructure in Python.

What's Next

The Trade Execution Engine decides what should happen.

The next challenge is remembering what has already happened.

Once the first order is executed, the platform becomes responsible for managing a living trading position that evolves over time.

In the next article, we'll explore how a production-ready Position Manager coordinates the complete lifecycle of a trade, including:

position lifecycle states;
partial Take Profit;
multiple Take Profit levels;
remaining quantity tracking;
Break Even activation;
Trailing Stop management;
Stop Loss transitions;
highest and lowest price tracking;
persistent position state;
recovery after application restart;
Spot and Futures lifecycle differences.

Along the way, we'll see why a Position Manager is much more than a collection of trading variables—it becomes the system's memory of the trading strategy.

Next: Building a Production-Ready Position Manager for Algorithmic Trading

https://dev.to/pydevtop/building-a-production-ready-position-manager-for-algorithmic-trading-55n4

Suggested DEV.to Tags

python
trading
architecture
websockets

DEV.to currently allows up to four tags per article, so using a focused set of highly relevant tags generally provides better discoverability than trying to cover every possible keyword.

SEO Keywords Covered

python trade execution engine
algorithmic trading platform
python trading architecture
position manager
state management
event-driven architecture
Bybit API Python
TradingView webhook Python
crypto trading automation
automated trading platform
Spot trading bot
Futures trading bot
Python WebSocket trading
trade signal routing
duplicate trading signals
persistent state
restart recovery
risk management engine
reverse trading signals
Dry Run Testnet Mainnet
Python fintech development

Building a Python Algorithmic Trading Platform with TradingView, Bybit API and WebSocket

PyDev — Wed, 15 Jul 2026 11:55:36 +0000

Series: Engineering an Algorithmic Trading Platform in Python

Part: 1 of 18

In this series

This series documents the engineering decisions behind building a production-ready algorithmic trading platform in Python. Rather than focusing on trading strategies, the articles explore software architecture, trade execution, risk management, real-time data processing, and system reliability.

Introduction

Most algorithmic trading projects begin with a deceptively simple idea.

Connect TradingView to an exchange API, receive webhook signals, execute market orders, and let automation handle the rest.

On paper, the architecture seems almost trivial.

TradingView
      │
Webhook
      │
Python Script
      │
Exchange API

After all, sending a POST request and placing a market order only takes a few lines of Python.

That assumption lasted exactly until the first real trading scenarios appeared.

The moment open positions had to survive an application restart, partial profits needed to be tracked correctly, stop losses had to move automatically to break even, and live market prices started arriving several times per second, the project stopped looking like a "trading bot."

It became a distributed software system with multiple independent components that had to cooperate reliably under constantly changing market conditions.

Over the past several months I've been building a modular algorithmic trading platform in Python. The original goal was never to create another "buy and sell" script. Instead, I wanted an architecture that could evolve over time without constantly rewriting core components every time a new feature appeared.

This article describes the engineering decisions behind that architecture, the problems that emerged during development, and why separating responsibilities between components made the system significantly easier to maintain.

Why Most Trading Bots Eventually Become Unmaintainable

Key idea

A trading bot becomes difficult to maintain when every feature is implemented inside a single execution flow.

One pattern appears repeatedly in open-source trading bots.

Everything happens inside one large function.

A webhook arrives.
The exchange API is called.
The position is updated.
Risk checks are performed.
Analytics are calculated.
Notifications are sent.

Eventually thousands of lines of business logic end up sharing the same execution flow.

Initially this approach feels productive because features can be added quickly.

Later, every modification becomes risky.

Adding a trailing stop unexpectedly breaks take-profit logic.
Implementing futures trading affects spot trading.
Introducing Telegram controls changes execution behaviour.

Instead of building another bot, I decided to build a platform.

From a Trading Bot to a Trading Platform

                    TradingView
                          │
                    FastAPI Webhook
                          │
               Trade Execution Engine
                          │
                  Risk Management
                          │
                 Position Manager
                 ┌────────┴────────┐
                 │                 │
          Spot Execution    Futures Execution
                 │                 │
                 └────────┬────────┘
                          │
                       Bybit API
                          │
                  Analytics Engine
                          │
               Telegram Control Panel

Each layer has a single responsibility.

Webhook validates requests.
Trade Execution Engine interprets signals.
Risk Manager applies trading rules.
Position Manager owns the lifecycle of positions.
Execution Layer communicates with the exchange.
Analytics processes completed trades.
Telegram provides operational control.

This separation dramatically reduced complexity as the project evolved.

Why the Webhook Should Never Execute Orders Directly

Many tutorials show something similar to this:

@app.post("/webhook")
def webhook(signal):
    client.place_order(signal)

While this is sufficient for a demo, production systems quickly expose its limitations.

Questions appear immediately.

What if TradingView sends the same webhook twice?
What if the exchange rejects the order?
What if another position is already open?
What if the signal arrives after market conditions have changed?

Instead, the webhook performs only three responsibilities:

Validate incoming requests.
Verify authentication and secrets.
Forward a normalized signal to the Trade Execution Engine.

Business logic belongs elsewhere.

Designing the Trade Execution Engine

The Trade Execution Engine became the heart of the platform.

Its responsibility is intentionally narrow.

It does not calculate indicators.

It does not generate analytics.

It does not manage Telegram.

It simply transforms validated signals into trading actions.

Typical actions include:

BUY_SPOT
SELL_FUTURES
CLOSE_POSITION

Before dispatching an order, the engine checks:

Is the trading pair enabled?
Is there already an open position?
Has this signal already been processed?
Does the current application state allow execution?

Only then does the execution layer communicate with the exchange.

About the Project

The examples shown throughout this series are taken from a personal algorithmic trading platform that I've been building and refining over the past several months.

The project continues to evolve as new engineering challenges appear during development.

Additional information about the platform is available here:

https://py-dev.top/application-software/bybit-signal-trading-bot

What's Next

In the next chapter, we move from the high-level platform architecture to one of its most important components—the Trade Execution Engine.

We'll explore how trading signals are transformed into controlled execution decisions, including:

Signal normalization
Action routing
Pair configuration
Duplicate signal protection
State-aware execution
Spot and Futures routing
Reverse signal handling
Dry Run, Testnet, and Mainnet execution
Error handling and execution flow

If you enjoyed this article, continue with Part 2:

➡️ Designing a Modular Trade Execution Engine in Python

https://dev.to/pydevtop/designing-a-modular-trade-execution-engine-in-python-5ebh

I Kept Missing Deals on Binance P2P — Until I Fixed the Real Problem

PyDev — Thu, 23 Apr 2026 08:45:32 +0000

I kept missing deals on Binance P2P.

And at some point, I realized:

every missed deal is just lost money.

Not because of bad prices.
Not because of competition.

But because I was too slow.

🧠 The problem nobody talks about

When people discuss Binance P2P trading, they focus on:

pricing strategies
arbitrage
ads
spreads

But almost nobody talks about this:

👉 execution speed

Here’s what actually happens:

buyer sends a message
you don’t see it immediately
buyer pays
you react too late
buyer loses trust
deal goes bad or gets canceled

All because of seconds.

🔁 My workflow was broken

My setup looked like this:

Binance open in one tab
Telegram in another
constant refreshing
switching between windows

It felt like I was working…

But in reality, I was lagging behind every deal.

💡 The realization

The problem wasn’t strategy.

The problem was friction.

Too many steps between:

message → reply
payment → release

And every extra step = delay.

⚡ I didn’t optimize price first — I optimized execution

Instead of building another dashboard…

I built something simpler:

👉 move the entire P2P workflow into Telegram

💬 Binance Chat → Telegram

Now every message appears instantly:

💬 Binance chat
#22880241441543839744
buyer: I sent the payment

No refresh. No tab switching.

Just real-time flow.

✍️ Reply instantly

I don’t open Binance chat anymore.

I reply directly from Telegram —
and the message goes back to Binance.

Fast. Clean. No friction.

💰 The moment that actually matters

The most important moment in P2P:

👉 when the buyer marks the order as paid

Before:

I had to notice it manually
open the order
verify everything
click release

Now:

The bot detects it instantly and shows:

✅ Order paid
👤 Counterparty
💰 Release Crypto button

⚡ One click → deal closed

I press one button:

👉 💰 Release Crypto

And the bot executes:

def ReleaseCrypto(self, order_number, pay_id=None):
    body = {"orderNumber": str(order_number)}

    if pay_id is not None:
        body["payId"] = int(pay_id)

    params = {
        "timestamp": self.getServerTime()
    }
    params["signature"] = self.getSignatureTrader(params)

    headers = {
        "X-MBX-APIKEY": self.getApiKey(),
        "clientType": "web",
        "Content-Type": "application/json",
    }

    response = requests.post(
        "https://api.binance.com/sapi/v1/c2c/orderMatch/releaseCoin",
        headers=headers,
        params=params,
        json=body
    )

    return response.json()

🚀 Real result

Crypto is released in under a second.

No UI.
No searching for the order.
No extra steps.

Just action → done.

📈 But here’s the second layer

Speed alone is not enough.

You also need to stay competitive on price.

So I added:

👉 auto price tracking (stepper logic)

The bot:

monitors competitors
adjusts price dynamically
stays in the top range
reacts to market changes

🧠 What this actually becomes

Not just a bot.

But a full P2P trading workflow system:

📊 price tracking
💬 chat handling
⚡ instant replies
💰 fast crypto release

🆚 Compared to typical P2P bots

Most bots focus on:

repricing
ad management
dashboards

This setup combines:

👉 price competitiveness + execution speed

Which is what actually wins deals.

🌍 Bonus

multi-language support
receipt (image) handling
clean Telegram interface
no unnecessary noise

⚠️ Important

This is not blind automation.

And not auto-release.

Everything is:

👉 manual decision
👉 instant execution

🔥 Final thought

I didn’t need a smarter strategy.

I needed a faster system.

Because in P2P:

price gets you the deal
speed closes it

TL;DR

I kept missing deals on Binance P2P
because I was too slow.

So I built a system that:

follows market price
syncs chat to Telegram
lets me reply instantly
detects payments
and releases crypto in one click

Now I don’t miss those moments anymore.

🚀 Try the bot

If you're interested in this workflow or want to test it:

👉 https://py-dev.top/application-software/p2p-binance-telegram-bot

Binance P2P Order History Fetcher with Full Name — Why I Built It (and Why Binance Export Is Useless for Accounting)

PyDev — Thu, 02 Apr 2026 11:25:10 +0000

How it started

A while ago I ran into a very practical problem.

I was working with P2P transactions on Binance and needed to prepare reports — not for myself, but for accounting.

At first I thought:

“Okay, Binance already has export. This should be easy.”

So I downloaded the P2P order history.

And… that’s where the problem started.

The moment I realized something is wrong

The export looked fine at first glance.

But then I noticed something critical:

👉 All names and surnames were hidden ().*

And that completely breaks everything.

Because for accounting, compliance, or any kind of reporting —

you NEED full names of counterparties.

Without that:

you can’t validate transactions
you can’t build proper reports
you can’t submit documents

Basically, the export becomes useless.

If you’ve ever tried to use Binance export for accounting — you already know the pain.

I ended up building a tool that actually solves this problem:

👉 https://py-dev.top/application-software/binance-p2p-order-history-fetcher-with-full-name

“But Binance gives it for free…”

Yes, Binance does provide a free export.

But let’s be honest:

👉 It’s not usable for any serious purpose.

The data is:

incomplete
anonymized
not suitable for accounting
impossible to properly process

It’s more like a viewer, not a real export.

And this is not a bug — it’s intentional.

Binance simply does not expose full names in their export.

The idea: what if I just automate it?

At that point I thought:

“Okay, I’ll just write a small script to fix this.”

Spoiler:

👉 It was NOT a small script.

The reality of building this tool

What seems simple at first actually involves:

working around Binance API limitations
handling authentication and requests properly
collecting full order data (not partial)
extracting real *full names instead of **
structuring everything correctly
exporting clean Excel reports

And most importantly — making it stable, not something that breaks after 2 runs.

That’s how Binance P2P Order History Fetcher with Full Name was created.

What the tool actually does

This is a Python-based tool that:

✔ fetches complete P2P order history

✔ retrieves full names and surnames (no masking)

✔ exports everything into a clean Excel file

✔ works for:

full year
specific months

What data you get

The generated Excel file includes:

orderNumber — order ID
advNo — advertisement ID
tradeType — buy/sell
asset — crypto (USDT, BTC, etc.)
fiat — fiat currency (USD, EUR…)
amount — crypto amount
totalPrice — total fiat value
unitPrice — price per unit
orderStatus — status
commission — fees
takerAmount — final crypto amount
payMethodName — payment method
Match time (UTC) — timestamp

And the most important part:

👉 Full Name (e.g., John Smith)

Why this actually matters

Let’s be clear.

Without full names:

reports are incomplete
accounting becomes manual hell
audits become risky

With full names:

you can generate real reports
you can use the data in accounting systems
you can actually TRUST your export

“It’s just a script, why is it paid?”

I literally got this comment yesterday:

“Binance gives it for free, this isn’t worth the money.”

Here’s the honest answer:

👉 If you think it’s “just a script” — try to build it.

Deal with:

API quirks
missing fields
hidden data
pagination
data consistency
Excel formatting

Then come back and say it’s “free”.

Because the real value here is not the code itself —

👉 it’s solving a problem Binance doesn’t solve.

Installation (quick overview)

Install Python

👉 https://py-dev.top/installing-python
Extract the archive to C:\
Open config.ini and configure parameters
Run start-the-program.bat

Final thoughts

Binance export is “free”.

But in reality:

👉 it’s incomplete and unusable for real workflows.

If you only need to “look at history” — it’s fine.

If you need:

accounting
reporting
real data

Then you need something more.

That’s exactly why I built this tool.

P2P Trade Bot for Binance – Smart Automation for P2P Traders

PyDev — Mon, 29 Sep 2025 13:00:22 +0000

The Engineering Behind a Binance P2P Price Tracking Bot: Automation & Execution Logic

In the fast-paced world of Binance P2P trading, maintaining a competitive position requires constant monitoring of market conditions, competitor pricing, and ad visibility.

Manual price updates are not only inefficient but also introduce latency — and in P2P markets, even small delays can result in lost trades or reduced profitability.

This article explores the internal logic and automation principles behind P2PTradeBot, a system designed to optimize ad positioning and price competitiveness on Binance P2P.

⚙️ The Core Problem: Manual Price Tracking

Most P2P traders face the same challenges:

Continuous monitoring of competitor ads
Manual price adjustments
Delays in reacting to market changes
Difficulty maintaining top positions

As market activity increases, manual interaction becomes a bottleneck.

🧠 Automated Price Tracking Engine

At the core of P2PTradeBot is a real-time price tracking system that continuously analyzes competitor ads and adjusts pricing dynamically.

Conceptual Logic:

Monitor selected competitors or full order book
Detect price changes in real time
Calculate optimal price based on strategy
Update ad price within predefined limits

This ensures that ads remain competitive without entering uncontrolled price drops.

🏗️ Execution Model

The system operates through three main components:

1. Market Monitoring Layer

Continuously fetches and analyzes Binance P2P ads, including:

Prices
Volumes
Payment methods
Seller types

2. Decision Engine

Applies user-defined rules:

Price thresholds
Competitor targeting
Volume filters
Payment preferences

3. Execution Layer

Handles automated price updates:

Keeps ads at Top 1 position
Applies safe price boundaries
Prevents unnecessary updates

🚀 Key Automation Features

Auto Top Positioning (Top 1)
Maintains leading position in P2P listings
Competitor Price Tracking
Reacts instantly to competitor price changes
Dynamic Filters
Select ads by volume, payment method, or seller type
Price Protection Logic
Prevents overpricing or aggressive undercutting
Multi-Ad Processing
Supports multiple listings simultaneously

📈 Performance & Efficiency

By automating price updates, the system:

Reduces manual workload
Minimizes reaction latency
Maintains consistent market positioning
Improves execution speed

This allows traders to operate efficiently even in high-frequency environments.

🛡️ Stability & Control

To ensure safe operation, the system includes:

Controlled update frequency
Filtering of irrelevant or inactive ads
Configurable price limits
Separation between logic and execution

This helps maintain stable behavior under varying market conditions.

🌐 Practical Use Case

A trader managing multiple Binance P2P ads can:

Automatically track competitors
Maintain top listing positions
Apply custom filters for payment methods
Adjust pricing strategy without manual input

⚡ Conclusion

Automation is no longer optional in Binance P2P trading.

Systems like P2PTradeBot allow traders to eliminate manual inefficiencies, maintain competitive pricing, and scale operations without constant supervision.

By combining real-time monitoring with rule-based execution, traders can achieve consistent performance in dynamic P2P markets.

Explore the project:

P2P Trade Bot for Binance – Automating Your Crypto Trading

PyDev — Fri, 26 Sep 2025 15:00:24 +0000

Managing P2P ads on Binance manually can be time-consuming and inefficient. The Binance P2P Trade Bot solves this by automating pricing, monitoring competitors, and keeping your ads optimized for maximum visibility and profitability.

For traders who want to automate P2P ads, check out the Binance bot here:

👉 https://arbitrage-scanner.io/crypto-trading-bot/p2p-trade-bot-binance

🔧 How the P2P Trade Bot Works

The bot constantly tracks competitor prices and adjusts your ads in real time.
This “Step / Follow Competitor” mechanism ensures your offers always remain attractive to buyers and sellers, while staying within the rules you define.

You set the strategy → the bot keeps your ads updated → you stay ahead in the order book.

🚀 Key Features

Multi-Processor Support
Efficient handling of large datasets and background tasks without delays.

Custom Seller Tracking
Choose to monitor a specific trader, only verified merchants, or all available sellers — with filters for minimum trade size.

Advanced Ad Control
Configure each ad with flexible criteria to maximize profit and precision.

⚡ Powerful Functions

AutoPilot (Top Position) → Keeps your ad at the very top of the P2P order book automatically.

Competitor Tracking → Dynamically adjusts your ad to match or beat chosen sellers.

Volume Filter → Targets ads based on transaction size.

Price Thresholds → Prevents pricing above/below your defined limits.

Payment Method Filter → Shows only ads with selected payment options.

Merchant/User Filter → Focus trading on verified merchants or all users.

Payment Time Filter → Exclude offers with slow settlement times.

Blacklist Feature → Block specific sellers by nickname so the bot ignores them.

💡 Why Use the Binance P2P Trade Bot?

This tool combines automation, competitor analysis, and granular filters to make your P2P trading faster, safer, and more profitable.
Whether you run ads manually or want full automation, the bot ensures your positions are always optimized to market conditions.

🛠 Installation Guide

Setting up the bot is straightforward. You’ll just need a Telegram bot and Python environment.

1. Create a Telegram Bot

Copy the API key and paste it into config.ini inside the P2PTradeBot folder:

BOT_TOKEN = 11111111:111111111

2. Install Python

Download and install Python from the official website
.

Unpack P2PTradeBot.zip to a folder (e.g., C:\P2PTradeBot).

Open config.ini and edit the parameters according to your trading setup.

3. Install Dependencies

Inside the bot folder, run:

install.bat

This installs all required Python packages.

4. Start the Bot

Run:

start.bat

Your Binance P2P Trade Bot will launch and begin executing trades automatically based on your configuration.

✅ With this bot, you no longer need to babysit your ads.
✅ Just configure once, and let automation do the heavy lifting.

How to Update Binance P2P Ad Price with Python: Complete Step-by-Step Tutorial

PyDev — Mon, 22 Sep 2025 08:24:28 +0000

Managing cryptocurrency trading on Binance can be time-consuming, especially for P2P merchants who need to constantly adjust ad prices to stay competitive. By using the Binance API with Python, you can automatically update your ad prices in real time and reduce the need for manual adjustments.

In this guide, you’ll learn:

Why automating Binance P2P ad price updates is important

What you need before getting started

A working Python script for editing ad prices

Common errors and how to fix them

Why Automate Binance Ad Price Updates?

Manual ad management on Binance P2P is inefficient and risky. Automating price changes provides several benefits:

⚡ Instant reaction to market fluctuations
📉 Lower risk of losses due to delays
💼 Optimized trading workflows
⏰ Significant time savings for merchants

Automation is particularly valuable if you’re running multiple ads or trading in highly volatile markets.

Requirements Before You Start

To programmatically change ad prices on Binance P2P, you’ll need:

Binance API keys (make sure you generate them from your merchant account).

Verified merchant account (only merchants can modify ads through the API).

Python with Requests library installed:
pip install requests

Python Code Example: Update Binance P2P Ad Price

Here’s a practical example of how to change an ad price using Python and the Binance API:

import time
import hmac, hashlib
import requests

class BinanceAPI:
    def __init__(self, api_key, api_secret):
        self.api_key = api_key
        self.api_secret = api_secret

    def getServerTime(self):
        return int(time.time() * 1000)

    def getSignature(self):
        query_string = f"timestamp={self.getServerTime()}"
        return hmac.new(
            self.api_secret.encode("utf-8"),
            query_string.encode("utf-8"),
            hashlib.sha256
        ).hexdigest()

    def getApiKey(self):
        return self.api_key

    def edit_ad(self, adv_num, new_price):
        payload = {'advNo': adv_num, 'price': new_price}
        params = {'timestamp': self.getServerTime(), 'signature': self.getSignature()}
        headers = {"Content-Type": "application/json", "X-MBX-APIKEY": self.getApiKey()}

        res = requests.post(
            'https://api.binance.com/sapi/v1/c2c/ads/update?',
            headers=headers, json=payload, params=params
        ).json()

        if res.get('code') == -1002:
            print("Access error: Merchant API keys required.")
        elif res.get('success'):
            print(f"Price updated: ad {adv_num} → new price {new_price}")
        else:
            print(f"Update error: {res.get('message', 'Unknown error')}")

        return res

Example Usage:

if __name__ == '__main__':
    api = BinanceAPI("YOUR_API_KEY", "YOUR_API_SECRET")
    api.edit_ad("1234567890987654321", "46")

Common Errors and Solutions

Error code -1002: Access denied → Use merchant API keys.

success: False: Incorrect ad ID → Verify ad number.

HTTP 401 or 403: Authorization issue → Double-check API key and secret.

Ready-Made Binance P2P Bot

If you don’t want to build everything from scratch, consider using a ready-to-use Binance P2P Trade Bot.
This bot automatically:

Monitors competitor prices

Adjusts your ads to stay competitive

Saves you time and increases efficiency

Final Thoughts

Automating Binance P2P ad price changes with Python is an essential strategy for serious crypto traders. It helps you:

Stay competitive in fast-moving markets

Reduce manual effort

Improve trading efficiency

Whether you’re creating your own Binance trading bot or just optimizing a few ads, Python + Binance API gives you full control over your P2P pricing strategy.

DEV Community: PyDev

Building a Production-Ready Risk Management Engine for Algorithmic Trading

About this series

The Problem Was Never Stop Loss

Why Simple Systems Lie

Execution Is Not Risk

The Evolution of the Trade Execution Engine

When "One More if" Became an Architectural Problem

Looking Beyond Stop Loss

Position Manager and Risk

Break Even Changed Everything

Trailing Stop Is Continuous Risk Evaluation

Reverse Signals Are Risk Decisions

Event-Driven Risk

Testing Strategy Changed Completely

Production Lessons

Engineering Means Preparing for Unknown Features

Future Evolution

Engineering Decisions That Changed the Platform

State became explicit.

Risk became continuous.

Components became independent.

Events became the language of the platform.

Engineering Principle

What's Next

Learn More

SEO Keywords Covered

Building a Production-Ready Position Manager for Algorithmic Trading

Introduction

The Illusion of Simplicity

The Real Problem Was State

State Belongs Together

The Position Manager Stopped Making Trading Decisions

Orders Are Events; Positions Are State

Price Updates Became Events

One Position Became Two Quantities

Remaining Quantity Became the Most Important Number

Break Even Is Not Just a Price

Why Trailing Stop Is Actually a State Machine

Persistent State Stopped Being Optional

Recovery Is Reconstructing Behaviour, Not Reloading JSON

Position Ownership Became Explicit

What the Position Manager Does Not Do

The First Useful Tests Were State-Transition Tests

Looking Back

Lessons Learned

Engineering Principle

What's Next

Designing a Modular Trade Execution Engine in Python

Introduction

the Trade Execution Engine

What the Trade Execution Engine Actually Does

Why the Webhook Should Not Contain Trading Logic

It becomes difficult to test

It becomes difficult to reuse

It becomes difficult to control

It becomes difficult to recover

Designing a Stable Signal Contract

Explicit Trading Actions Are Better Than Ambiguous BUY and SELL

Loading Pair Configuration

Rejecting Unknown and Disabled Pairs

Separating Spot and Futures Execution

Spot BUY

Futures short

A Practical process_signal() Structure

State Awareness Before Execution

No open position

Existing short position

Existing Spot position

Position already closing

Pair disabled after the signal was generated

Reverse Signals Need a Defined State Transition

Duplicate Signal Protection

Signal ID

Time-window fingerprint

State-based rejection

Idempotency and Race Conditions

Execution Modes: Dry Run, Testnet, and Mainnet

Dry Run

Testnet

A Practical `process_signal()` Structure