Dynamic Pricing in Travel and Airlines: Building Offers That Move With the Market

In June 2026, IATA cut its industry forecast to a $23.0 billion net profit on $1.165 trillion of revenue - a 2.0% net margin, or $4.50 per passenger carried. The cause was not demand. It was cost: jet fuel repriced from $90 to $152 per barrel, a 69% jump in twelve months (IATA, June 2026).

At $4.50 per passenger, a pricing rule that fires two hours late is not an optimization problem. It is the margin.

That is the context in which dynamic pricing in travel stopped being a revenue-management experiment and became infrastructure. Dynamic pricing in travel is no longer one team’s optimization project; it is the layer through which every booking passes. Airlines, hotel groups and tour operators are all solving the same mechanical problem: dozens of inputs that change hourly - fuel, FX, occupancy, load factor, competitor moves, event calendars, ancillary attach rates - have to resolve into one number, in milliseconds, across every channel, with an audit trail a regulator can read.

This article covers how that machinery works, what breaks in the traditional approach, and where a business rules engine like Higson sits relative to the revenue-management systems you already run.

What dynamic pricing in travel actually means: three distinct capabilities

The term gets used loosely. IATA separates it into three capabilities that are often confused, and the distinction matters because each one demands something different from your systems (IATA, Dynamic Offers):

• Dynamic pricing - prices calculated from contextual information available at the moment of shopping, rather than pulled from a static fare or rate table.

• Continuous pricing - an indefinite number of price points instead of fixed booking classes or rate buckets, so the price can track supply and demand granularly.

• Dynamic bundling - ancillaries and add-ons priced individually per request, based on demand, availability and inferred willingness to pay.

IATA’s own modelling, drawing on MIT research, puts continuous pricing alone at a 1–2% revenue increase, dynamic bundling of ancillaries at up to 2.6% net revenue, and the two combined with dynamic flight pricing at up to 12%. Across the industry, modern retailing capability is valued at roughly 4% in new annual value - about $7 per passenger (IATA, Creating Value in Airline Retailing).

Set that $7 against IATA’s $4.50 net profit per passenger and the business case answers itself.

Most carriers and hotel groups are somewhere on step one. They have dynamic pricing on the base fare or the room rate, and static pricing on everything else - which is where a growing share of the money now lives. IATA’s Modern Airline Retailing programme frames the end state as offer-and-order based selling, in which the price, the bundle and the fulfilment record are all constructed per request rather than assembled from fixed inventory classes.

The ancillary shift: why the bundle is now the product

Worldwide airline ancillary revenue reached $148.4 billion in 2024, against a 2019 record of $109.5 billion. Per-passenger ancillary revenue rose 2.5% in that year while base fares fell 3.8%. Five carriers - Frontier (62.0%), Spirit (58.7%), Volaris (55.3%), Breeze (54.0%) and Allegiant (52.9%) - now take more than half their revenue from ancillaries rather than fares (IdeaWorksCompany, 2025 Yearbook of Ancillary Revenue).

The five largest US airlines generated over $28 billion from frequent-flyer programs in 2024, an average of $35.48 per passenger - nearly eight times the net profit per passenger IATA forecasts for 2026.

The implication for pricing architecture is direct. If more than half your revenue comes from bags, seats, meals, priority boarding, bundles and loyalty redemptions, then a pricing engine that only prices the fare is pricing the minority of your business. The offer - fare plus ancillaries plus loyalty treatment plus channel-specific terms - is the unit that has to be priced dynamically. Hotels face the mirror image: room rate plus meal plan plus spa plus parking plus late check-out, assembled per request.

The anatomy of a travel price

Before you can automate a price, you have to model what it is made of. Neither an airline ticket nor a hotel rate is a margin calculation on a base cost.

Airline fare components

• Base fare - route, booking class or continuous price point, seat availability

• Fuel surcharges - tracking Brent and jet-fuel movements, with hedging position applied

• Airport and passenger fees - varying by origin and destination

• Taxes and levies - VAT, environmental charges, government fees

• Baggage - increasingly unbundled and priced per segment

• Seat selection - premium locations, extra legroom, family adjacency

• Ancillaries - meals, priority boarding, lounge access, fast-track, carbon offset

Hotel rate components

• Base rate - room type and category

• Seasonality - peak, shoulder and off-peak calendars

• Occupancy - yield management as the house fills

• Length of stay - LOS discounts, minimum-stay restrictions during events

• Meal plan - room-only, BB, HB, FB, all-inclusive

• Add-ons - spa, parking, late check-out, airport transfer

• Channel - direct, OTA, metasearch, tour operator, corporate contract

Package pricing: where the components collide

Dynamic packaging is the hardest case and the most valuable one. A flight-plus-hotel-plus-transfer package has to sum live components from three independent inventories, apply package-level margin rules, and return a bookable price - not an estimate that changes at checkout. The customer sees one number. Behind it sit three availability checks, a currency conversion, a margin floor and a set of promotional eligibility rules, all resolved inside the page load.

That is a latency problem before it is a pricing problem, which is why the calculation layer matters as much as the logic.

Why rate cards and spreadsheets stop working

For years the industry managed this with static rate cards, manual corrections by revenue managers and hardcoded “if-then” logic inside the reservation system. Four failure modes recur across every travel operator we work with.

The four failure modes of static pricing

Reaction time. A change to a fuel surcharge or a competitive response has to move through a change request, a development sprint and a release window. By the time the price reaches every channel, the market that justified it has moved. Fuel rose 69% in a year - annual rate-card cycles cannot absorb that.

Logic trapped in code. When pricing rules live inside the booking engine, the revenue manager who understands the commercial intent cannot change them. Every adjustment becomes an IT ticket, and the ticket queue becomes the ceiling on how often you can reprice. This is the same bottleneck insurance product teams hit when pricing logic is buried in a policy administration system - the pattern is described in detail in our guide to what a rules engine is and how it works.

Channel drift. Direct site, OTAs, metasearch and tour-operator feeds each get their price from a different process, on a different schedule. The result is inconsistency customers notice and a distribution strategy nobody actually controls.

No audit trail. When a regulator, a partner or your own finance team asks why a specific customer saw a specific price on a specific date, a spreadsheet-and-release-notes answer is not an answer. As the next section shows, that question is now being asked with statutory force.

Dynamic pricing is now a disclosure and audit problem

This is the change that most travel pricing roadmaps written before 2025 do not account for.

United States: disclosure, algorithmic coordination and congressional scrutiny

New York. The Algorithmic Pricing Disclosure Act (N.Y. Gen. Bus. Law § 349-a) took effect on 10 November 2025. Where a price is set by an algorithm using a consumer’s personal data, the seller must display: “THIS PRICE WAS SET BY AN ALGORITHM USING YOUR PERSONAL DATA.” Civil penalties run to $1,000 per violation, and the law survived a First Amendment challenge (Skadden, January 2026).

California. AB 325 took effect 1 January 2026, addressing the use of common pricing algorithms in anticompetitive arrangements.

Maryland passed the Protection from Predatory Pricing Act, treating certain personalized-pricing practices as deceptive trade practices, and bills restricting or requiring disclosure of algorithmic pricing were introduced in Tennessee and New Mexico for the 2026 sessions (Holland & Knight, April 2026).

Federal. The FTC’s Section 6(b) surveillance-pricing study found a wide range of personal data feeding individualized prices (FTC, January 2025), and in August 2026 the Commission proposed an enforcement policy statement on personalized pricing, aimed at requiring sellers to disclose when personalized pricing is in use (Alston & Bird, August 2026). The House Oversight Committee opened an investigation into revenue-management algorithms and pricing practices on 5 March 2026.

Europe: the end of contractual rate parity

Europe. The Court of Justice of the European Union ruled on 19 September 2024 that Booking.com’s price parity clauses - both wide and narrow - are not objectively necessary to the platform’s main operation, removing the contractual basis for parity enforcement across the EU. Booking.com was separately designated a gatekeeper under the Digital Markets Act in 2024 (Legal Dive).

What this means for your pricing architecture

Two consequences follow for anyone running dynamic pricing in travel. First, you need to know which inputs drove any given price, for any given request, months after the fact. Second, parity is no longer a contract term you inherit - it is a commercial decision you make and must be able to defend, channel by channel.

Both are properties of a rules engine, not of a pricing model. A model produces a number. An engine produces a number plus the versioned record of the rule set, the input values and the decision path that produced it.

Pricing model versus pricing engine: the distinction that shapes your architecture

This is the point travel teams most often collapse, and it is worth stating plainly.

Two layers, two jobs

A pricing model - a demand forecast, an elasticity curve, a willingness-to-pay estimate - answers what should the price be. Revenue-management platforms, forecasting tools and machine-learning models do this well, and most travel operators already own one.

A pricing engine answers what price is actually served. It takes the model’s recommendation and applies everything the model does not know: contractual floors, corporate rates, promotional eligibility, channel terms, regulatory disclosure requirements, margin protection, currency rounding rules, group and loyalty entitlements. It does this per request, at page-load speed, with an audit record.

Why this is a complement, not a replacement

These are complementary layers, not competing products. We see the same pattern in insurance: actuarial and AI pricing platforms build the models; a business rules engine deploys them inline at execution speed. The logic is identical in travel - your revenue-management system keeps forecasting, and the engine executes its output under guardrails. If what you need is a better demand forecast, a rules engine is the wrong purchase. If what you need is to get a decision into production this afternoon instead of next quarter, it is the right one.

The same separation is explained from the decisioning side in what a decision engine is and how it differs from a model.

How Higson runs dynamic pricing for airlines, hotels and packages

Higson is a Business Rules Management System and product configurator. In travel, it sits between your inventory and forecasting systems and your distribution channels, and it holds the commercial logic that turns inputs into a served price.

Four layers

Input layer. Pulls availability from GDS/CRS, occupancy from channel managers, and external signals through APIs - jet fuel and Brent quotes, FX rates, weather, event calendars, competitor rate feeds.

Business logic layer. Where base rules, modifiers, eligibility conditions and margin safeguards are defined - as decision tables, not code. Higson supports rule authoring aligned with the OMG DMN standard for decision tables and expression logic, which keeps the logic portable and readable by non-developers.

Calculation layer. Resolves the optimal price for revenue and the minimum price for profitability, per request. Typical rule execution is 0.23 ms, with sustained throughput of 9,000 requests per second - the headroom that makes live dynamic packaging viable rather than a spinner on a checkout page.

Distribution layer. Propagates prices and restrictions to direct sites, OTAs, metasearch and partner feeds from a single source of logic, so channel-specific terms are an explicit rule rather than an accident of scheduling.

Decision tables the revenue manager owns

The operational change most travel teams underestimate is who edits the rules. In Higson Studio, a revenue manager reads a decision table as a grid: conditions in the left-hand columns, the resulting modifier on the right. Changing a fuel-surcharge threshold or adding a last-minute occupancy trigger is an edit, a test against historical bookings, and a versioned deployment - not a sprint.

We see the same shift in insurance product teams, where business analysts move from filing tickets to authoring rules directly; the mechanics are covered in our article on elastic pricing and real-time rate adjustments.

Guardrails as first-class rules

Dynamic pricing without constraints is how operators end up in the news. In practice the guardrails carry as much weight as the optimization:

• Floor price per route, room type or package, below which no modifier chain can push

• Margin protection applied after all discounts and promotions resolve

• Parity policy expressed explicitly per channel, now that it is a choice rather than a contract term

• Disclosure flags raised automatically when personal data enters the calculation, so the interface can render the notice New York requires

• Rate-of-change limits so an input spike cannot move a published price further than commercial policy allows

Performance in production, cross-vertical

The execution profile is not a travel-only claim. In Notus Finance’s real-time offer management deployment, a migration to Higson took a 100,000-calculation batch from 14 seconds to 8. At TUW, motor insurance pricing was accelerated using the same engine. Price assembly under real-time constraints is the same computer-science problem in aviation, lodging, lending and insurance - only the vocabulary changes.

Where the value shows up: airlines, hotels, OTAs

Airlines: surcharges and ancillaries

Dynamic surcharge management is the immediate win in a year when jet fuel moved 69%: fuel and currency modifiers recalculated against live quotes and hedging position, per route, without a release. Beyond that, ancillary pricing - bags and seats priced against passenger profile, channel and time-to-departure - is where IATA locates up to 2.6% of net revenue.

Hotels: yield, restrictions and the parity decision

Automatic rate adjustment as occupancy builds, last-minute release rules for unsold inventory, minimum-stay restrictions applied automatically around event dates, and - post-CJEU - an explicit, defensible position on channel parity with direct-only offers configured as rules rather than manual overrides.

Tour operators and OTAs: live packaging

Dynamic packaging that sums live flight, hotel and transfer components per request, and repricing rules that run continuously instead of consuming the revenue team’s week. The same central-catalogue pattern is used outside travel - see how it works in retail price management and in telecom tariff and bundle management.

For the operational side of airline decision automation - irregular operations (IROPS), maintenance, crew and fuel logistics rather than price - see how business rules engines improve airline operations and the broader overview of BRMS use cases for airlines.

What travel teams can borrow from insurance pricing

Insurance has run regulated, audited, real-time pricing for longer than travel has, under constraints travel is only now acquiring. Three practices transfer directly.

Measure leakage, not just uplift. Insurers audit the gap between the price the rules should have produced and the price actually charged. In legacy environments that gap typically runs 3–7% of premium; disciplined rules-based execution brings it to 1–2%. Travel operators rarely measure the equivalent - the revenue lost to stale rate cards, failed promotional exclusions and channel drift. It is usually larger than the uplift being chased. The measurement approach is set out in insurance premium calculation.

Treat every rate change as a filed artifact. US insurers coordinate rate changes across 51 regulatory jurisdictions, each with its own filing requirements, which forces rule versioning and state-level isolation as an architectural default. Travel now has a weaker but real version of the same problem: New York requires a disclosure, California constrains algorithmic coordination, the EU has removed parity cover. Jurisdiction-scoped rule sets are the pattern that answers both. Our analysis of insurance pricing rules and dynamic rate adjustments covers the mechanics.

Separate the model from its execution. Insurers deploy actuarial and machine-learning models into a rules engine that enforces regulatory guardrails around them, rather than letting a model serve prices directly. That separation is what makes an AI-assisted price defensible. The same argument applies to dynamic pricing strategy generally and to dynamic pricing engines in financial services.

The adjacent disciplines are worth reading across, too: risk-based decisioning is covered in our underwriting automation guide, and post-sale rule execution in claims management with business rules engines.

Where Higson fits - and where it does not

Higson is a good fit when your constraint is execution: pricing logic is trapped in application code, changes take weeks, channels drift apart, and you cannot reconstruct why a price was what it was. It is built for operators who need business users editing rules directly, sub-millisecond assembly for live packaging, and a versioned audit trail.

It is the wrong tool in three cases, and we would rather say so now than in month four of an implementation.

Three cases where you should buy something else

If you need better demand forecasting or elasticity modelling, that is a revenue-management and data-science problem. Higson executes those models; it does not build them, and a specialist forecasting platform will serve you better as the source.

If your pricing is genuinely simple - a small property portfolio on seasonal rate cards, a charter operator with fixed allocations - a rules engine is more machinery than the problem needs.

If you require sustained throughput far above 9,000 requests per second at peak, typical of the largest global metasearch and OTA workloads, that is an architecture conversation before it is a product conversation. Tell us the peak number early.

FAQ

What is the difference between dynamic pricing, continuous pricing and dynamic bundling in travel?

Dynamic pricing calculates a price from live context at the moment of shopping. Continuous pricing removes fixed booking classes or rate buckets so prices can take any value along a curve. Dynamic bundling prices ancillaries and add-ons individually per request. IATA treats them as three separate capabilities; most operators have the first and are working toward the other two.

How much additional revenue can dynamic pricing realistically generate for an airline?

IATA’s modelling, drawing on MIT research, puts continuous pricing at 1–2% revenue uplift and ancillary dynamic bundling at up to 2.6% net revenue, with up to 12% when combined with dynamic flight pricing. Industry-wide, modern retailing capability is valued at roughly 4% in new annual value, about $7 per passenger.

Do I need a rules engine if I already run a revenue management system?

They solve different problems. A revenue management system forecasts demand and recommends a price. A rules engine applies contractual floors, channel terms, eligibility, margin protection and disclosure requirements to that recommendation and serves the result in milliseconds with an audit trail. Most mature travel stacks run both.

What does the New York Algorithmic Pricing Disclosure Act require from travel companies?

Since 10 November 2025, where a price shown to a consumer was set by an algorithm using that consumer’s personal data, New York requires the disclosure “THIS PRICE WAS SET BY AN ALGORITHM USING YOUR PERSONAL DATA,” with civil penalties up to $1,000 per violation. Operationally, this means your pricing system must know when personal data entered the calculation.

How do hotels handle rate parity after the EU Booking.com ruling of September 2024?

The Court of Justice of the European Union held that both wide and narrow price parity clauses are not objectively necessary to the platform’s operation, so parity is no longer imposed contractually across the EU. Hotels now set channel policy themselves, which means parity, near-parity or deliberate direct-only differentiation should be configured as explicit rules with a recorded rationale.

How fast does a pricing engine need to be for live dynamic packaging?

Fast enough that summing live flight, hotel and transfer components does not delay the page. Higson’s typical rule execution is 0.23 ms with sustained throughput of 9,000 requests per second, which leaves the latency budget to the inventory calls rather than the pricing logic.

Can revenue managers change pricing rules without involving the IT department?

Yes - that is the main operational reason to separate rules from application code. In Higson Studio, rules are authored as decision tables, tested against historical data and deployed with version control. Complex algorithmic logic still benefits from engineering involvement, but routine modifiers, thresholds and eligibility conditions are business-owned.

What guardrails should be in place before turning on dynamic pricing in travel?

At minimum: a floor price per product, margin protection applied after all promotions resolve, rate-of-change limits so an input spike cannot move a published price beyond policy, explicit per-channel parity rules, and automatic disclosure flags when personal data enters the calculation.

How long does it take to implement dynamic pricing in travel with a business rules engine?

Scope one product line and one channel first - a single route family or property cluster with clear commercial ownership. A proof of concept on AWS Marketplace runs at $0.63 per hour, which lets you model your own logic before any procurement commitment. Full production deployments across a portfolio typically run 3–6 months.

Does dynamic pricing work for tour operators selling multi-component packages?

It is the strongest case for it, because package prices decay fastest. Live assembly of flight, hotel and transfer components with package-level margin rules produces a bookable price rather than an estimate that changes at checkout - which is the difference between a conversion and an abandoned basket.

Talk to Higson about your pricing logic

Jet fuel moved 69% in a year and the industry’s net profit landed at $4.50 per passenger. Whatever your pricing roadmap said in January, the margin for slow rule changes has gone.

The question worth answering first is not which vendor to buy. It is a diagnostic one: how long does it currently take you to change one pricing rule and have it live on every channel? If the honest answer is measured in weeks, the gap between your forecast price and your served price is costing more than any uplift project will recover.

Two ways to test that without a procurement cycle:

• Run a proof of concept on AWS Marketplace at $0.63 per hour, using your own rules and your own data.

• Book a working session - we will model one live pricing scenario from your portfolio against your current change-cycle time, and you will see the delta in the session rather than in a deck.

If you are earlier in the evaluation, the Business Rules Engine Comparison guide covers how to assess BRMS vendors, including the questions that separate execution engines from modelling platforms. Or start with the dynamic pricing use case and the product catalog use case for how the pieces fit together.