Building a Rule-Based Pricing Engine for a P2P Marketplace

At first glance, automated P2P repricing looks like a trivial programming task.

Fetch the order book, find the best competitor, calculate a slightly better price and update your advertisement.

A basic prototype can indeed be built around that idea.

A production-oriented pricing engine is considerably more interesting.

The difficulty isn’t changing a number through an API.

The difficulty is deciding which number should replace it.

Step 1: Market Data

Every repricing cycle starts with market information.

The application needs the advertisements relevant to the current asset, fiat currency and trading direction.

But raw marketplace data shouldn’t necessarily be fed directly into the pricing algorithm.

There may be dozens of offers that technically belong to the same market while being irrelevant to the strategy being executed.

That leads to the second stage.

Step 2: Filtering

Consider two USDT advertisements with similar prices.

One accepts the payment method used by your strategy.

The other doesn’t.

Should they have equal influence on the target price?

Probably not.

The same issue appears with transaction limits, merchant characteristics and available volume.

A pricing engine therefore benefits from treating filtering as a separate stage:

market → candidates → relevant competitors

This architecture also makes the system easier to reason about.

Instead of asking why the algorithm selected a strange price, you can first inspect which advertisements were allowed into the candidate set.

Step 3: Competitor Selection

Once irrelevant offers have been removed, the application needs a reference.

This might be the best remaining price.

It could also be a particular market position or a selected competitor.

Different strategies can use different selection mechanisms while sharing the same underlying market-data and filtering components.

This modularity becomes especially useful when multiple advertisements are managed simultaneously.

Step 4: Calculate the Target

Now the actual pricing rule can be applied.

A simple implementation might add or subtract a configured offset from the reference price.

More advanced implementations can incorporate thresholds or other market-derived values.

The important architectural point is that target calculation and validation should not be the same operation.

First calculate what the strategy wants.

Then determine whether the system should actually use it.

Step 5: Apply Safety Boundaries

Suppose the calculated target is mathematically correct but economically unacceptable.

The application needs a mechanism to reject it.

For example:

market data
    ↓
filters
    ↓
competitor selection
    ↓
target price calculation
    ↓
minimum / maximum / spread checks
    ↓
valid?
 ┌──┴──┐
 no   yes
 ↓     ↓
skip  update

This is one of the most important differences between a repricing script and a pricing engine.

The script knows how to change a price.

The engine knows the conditions under which changing the price is permitted.

Step 6: Update Only When Necessary

There is little value in repeatedly sending an update if the calculated price is already equal to the current advertisement price.

A sensible execution layer therefore compares the target with the current state before making a change.

After that, the monitoring cycle begins again.

Conceptually:

fetch → filter → select → calculate → validate → update → repeat

This is a straightforward architecture, but it provides a foundation on which considerably more sophisticated strategies can be built.

Build It or Use an Existing Implementation?

For developers, building such a system can be an interesting project.

The challenge is that the pricing algorithm is only part of the work.

You also need configuration management, API integration, error handling, continuous operation, support for multiple advertisements and practical mechanisms for controlling the running process.

For someone interested in examining an existing self-hosted implementation rather than starting from zero, PyDev develops a Python-based P2P Trade Bot built around automated advertisement management, competitor filtering and configurable pricing rules.

The self-hosted approach is particularly interesting from a developer perspective because the application runs on infrastructure controlled by the operator rather than requiring all trading logic to be delegated to an external SaaS dashboard.

Keep the Strategy Outside the Plumbing

One architectural lesson applies beyond P2P trading.

Business rules should ideally be separated from infrastructure.

API authentication shouldn’t determine pricing strategy.

Telegram or another control interface shouldn’t contain the core pricing logic.

Market retrieval shouldn’t decide risk limits.

When those responsibilities are separated, strategies become easier to modify and the system becomes easier to test.

This also makes future expansion easier.

A new pricing strategy can potentially reuse the same market retrieval, filtering, validation and execution layers.

Automation Is Mostly About Repetition

There is nothing magical about this architecture.

And that’s actually a good thing.

A reliable trading automation system doesn’t need mysterious behavior.

It needs to repeatedly take market information, apply explicitly defined rules, reject unsafe results and execute valid changes.

The interesting engineering challenge isn’t teaching a machine how to trade.

It’s turning a trader’s repetitive decisions into deterministic software.