Right offer, right member, right rate.

Any lending product where a rate, limit, term or offer is set and an outcome follows: personal loans, car and secured lending, credit cards, overdrafts, home loans and SME facilities. Channels are handled separately rather than averaged, because branch, online and broker applicants behave differently at the same price and a single elasticity curve across all three is usually wrong.

Technically the engine can reprice as often as your data arrives, including daily. In practice lending rarely should. Advertised rates carry approval and disclosure obligations, and an engine that changes a headline rate faster than your governance can follow creates a conduct problem rather than a margin gain. We normally recommend a monthly cadence with an on demand run when the market moves, and the cadence is a rule you set rather than something the engine decides. Existing contracts are never repriced.

Product, term, channel, risk band, tenure and segment, down to whatever your systems can actually apply. We do not recommend a distinct price per individual even where it is technically possible; in consumer lending that raises fairness and explainability questions that are hard to answer in front of a regulator, and the margin difference over well built segments is small. The engine will hold segment sizes to a floor you set.

Optimisation runs on segments rather than on individuals, so the problem size is set by products, terms, channels and bands rather than by member count. Books in the hundreds of thousands are routine at this shape. The binding constraint is almost never compute; it is how much rate variation your history contains.

Rate and rate tiers, limits, term, fee structure, offer eligibility, retention offers for members at refinance risk, and the size and timing of campaigns. Scenarios can be simulated before anything goes live: what a quarter point move does to take up, attrition, return on assets and the book, with the uncertainty around each.

Yes. Consumer rates are published, so a feed of competitor and comparison site rates is collected on a schedule and carried into the optimiser as a market position rule rather than as background reading. If you already licence a competitive feed we use it; if not, published rates cover most of what matters for consumer products.

Sometimes, and the honest answer comes from looking rather than from a claim. Declined and lapsed quotes usually carry enough rate variation to start, and existing tier boundaries give a natural experiment either side of each cut off. Where both are thin for a segment, the curve is marked unreliable rather than smoothed over, and a short rate trial answers it properly.

That is why objectives are weighted rather than ranked. Return on assets, growth, retention and member benefit are optimised together, and the frontier between them is shown so the board approves a position rather than inherits one. A single objective optimiser is the wrong tool for a mutual, which is most of why the generic pricing tools do not fit.

Exclusions are enforced inside the optimiser rather than applied afterwards, so hardship flags and eligibility rules bind before a rate is proposed. Every price is recorded with the inputs, weights and constraints in force, and each one reports which constraint bound it. That is the evidence a design and distribution review asks for. It does not replace your compliance framework; it produces what the framework requires.

We read from wherever your data already lives: a warehouse such as Snowflake, Databricks, BigQuery or SQL Server, extracts from your core banking and origination systems, or a secure file transfer if that is simpler. Outputs come back as a rate card file, an API call at quote time, or a table in your warehouse. A first engagement usually runs on an extract, with integration only once the value is proven.

By holding a control group and reading the difference. Volume alone cannot tell you, because a campaign always books volume. The read out separates what the change added from what would have happened anyway, and reports it after funding, expected loss and servicing.

LuminoEvidence builds the risk model that sets the floor beneath the price. LuminoTrial runs the rate trials where history cannot answer the question. LuminoOffer sets the price and measures what it earned. They are bought separately and designed to compound.