What is Straight-Through Processing (STP) in Insurance?

Straight-through processing (STP) in insurance is the completion of a transaction, such as a quote, bind or simple claim, from start to finish by systems alone, with no person reviewing or rekeying it. Rules decide which transactions qualify, and the rest are referred.

This guide is for insurance operations, IT and product teams. It covers where STP applies across the policy lifecycle, what makes a transaction suitable, how referrals work, what blocks STP and how to measure it.

What straight-through processing is

A transaction is processed straight through when it enters a system and leaves it complete, with every check, calculation and document handled automatically. A broker submits a small business package through a portal; the system validates the data, enriches it with property and company information, applies the underwriting rules, rates the risk, binds the cover, takes payment and issues the documents. Nobody at the insurer or MGA touches it.

The term came from banking and securities settlement, where it described trades that passed from order to settlement without manual intervention. In insurance it applies to any transaction in the policy or claims lifecycle that can be completed by rules.

STP is selective by design. Insurers do not aim to process every transaction straight through. They aim to process the straightforward ones automatically so that underwriters and handlers spend their time on the risks and claims that need judgement.

Where STP applies

Quote and bind is the most common use. Personal lines, small commercial and high-volume specialty products such as travel, gadget or landlord cover are often quoted and bound straight through on broker portals, price comparison sites and embedded insurance journeys, because the risks are similar and the rules are well established.

Policy issuance follows from bind. Once a risk is accepted, the system produces the schedule, certificate, policy wording and any statutory documents, and sends them to the policyholder and broker. Where documents are produced from templates and policy data, issuance can be part of the same automated step.

Mid-term adjustments, recorded as endorsements, are well suited to STP when the change is within the rules: adding a vehicle to a fleet within the rating guide, changing an address or increasing a sum insured below the referral threshold. The system rerates, calculates the additional or return premium and issues the endorsement.

Renewals can be processed straight through when the policy has had no claims or material changes and the renewal rate falls within agreed limits. The system identifies policies due, rerates them, applies the renewal rules and issues renewal documents, referring those that breach a rule.

Billing covers instalment plans, payment collection, failed payment handling, refunds and commission calculation. These are rule-driven by nature and are often the first area automated.

Simple claims, such as low-value glass, gadget or travel claims with clear evidence, can be settled straight through after automated checks on cover, excess and fraud indicators. More complex claims usually use automation for part of the journey, such as first notification of loss and triage, with a handler making the decision.

What makes a transaction suitable for STP

Clean data is the first requirement. A transaction can only be processed automatically if the system receives all the information it needs, in a form it can read. Structured fields from a portal or API qualify. An email with a spreadsheet attached does not, until someone extracts the data.

Clear underwriting rules are the second. The insurer has to be able to write down, in terms a system can apply, which risks it will accept, at what price and on what terms. For a small business package that might mean accepted trades, maximum sums insured, minimum security requirements, claims history limits and postcode restrictions. Where acceptance depends on judgement, such as the quality of a risk survey or the experience of a management team, STP is harder.

Defined authority limits are the third. Under delegated authority, an MGA can only bind what its binding authority allows, so the system needs to hold those limits and check every transaction against them. A risk within the MGA's authority and the insurer's appetite can be processed straight through. A risk above a limit has to be referred.

STP and referrals: how rules decide what is processed automatically and what goes to an underwriter

Every STP process has a referral path. The underwriting rules sort each transaction into one of three outcomes: accept, decline or refer. Accepted transactions proceed automatically. Declined transactions are stopped with a reason. Referred transactions go to an underwriter's queue with the data, the rules triggered and a recommended action.

Typical referral triggers include a sum insured above a threshold, a trade or activity outside the standard appetite, a claims history beyond set limits, a postcode in a high flood or subsidence risk area, a data enrichment result that contradicts the broker's answers and a premium change at renewal above a set percentage.

The referral rules are where an insurer controls the balance between automation and oversight. Tight rules refer more business and protect the portfolio at the cost of underwriter time. Loose rules process more straight through and rely on the rules being right. Most insurers start tight and loosen rules as they gain confidence from the referral data, for example by raising a threshold once they can see that most referrals at that level are accepted unchanged.

What blocks STP

Legacy systems are the most common block. Many older policy administration systems were built for screen-based processing, with rating, documents and billing in separate steps that need a user to move the transaction along. Some rules are hard-coded, so changing a referral threshold needs a developer.

Manual data re-entry breaks STP at every point it occurs. If broker submissions arrive by email and are keyed into the system, the transaction is manual from the start, however automated the later stages are. Rekeying also introduces errors that cause later steps to fail.

Unstructured submissions are a particular problem in commercial and specialty lines, where risks arrive as broker presentations, schedules of values and loss runs in documents and spreadsheets. Document extraction tools and agentic AI are increasingly used to turn these into structured data, with a person checking the result.

Missing integrations stop STP part way. If the system cannot call a property data service, a payment provider or a sanctions screening service, someone has to do that step by hand. Each missing connection is a point at which the transaction stops.

Measuring STP: STP rate, referral rate and time to issue

The STP rate is the share of transactions completed with no manual intervention, measured separately for each transaction type and product. A combined figure hides too much: a 90% rate on renewals and a 20% rate on new business tell a different story from a 55% average.

The referral rate is the share of transactions sent to an underwriter or handler. Track it alongside the outcome of each referral. If most referrals for a trigger are accepted unchanged, the trigger may be too tight. If many are declined or re-priced, it is working.

Time to issue measures how long a transaction takes from submission to completed documents. For straight-through transactions it should be seconds or minutes. For referred transactions it shows how quickly the underwriting team responds, and long times often point to queues that more STP would relieve.

Firms also track the reasons transactions fall out of STP, such as missing data, failed integrations or rule breaches. That breakdown shows where to invest next, whether in better portal questions, a new data integration or a rule change.

How this applies to policy administration

STP depends on the policy administration system holding the product, rating, underwriting rules, authority limits and document templates as configuration, so that a transaction can move from quote to issued documents in one automated flow and the rules can be changed by the business as referral data comes in. Genasys describes on its policy administration page a configurable rules engine for endorsements, excesses and refer or decline decisions, and renewals that can be invited, re-rated and issued automatically based on the insurer's rules. Configuring and launching products is covered on our speed to market page.