Fraud checks for night loan applications need history

You are about to switch on a rule that sends every cash-loan application started between midnight and five in the morning for review. The overnight list is already taking shape: a Saturday application sits at the edge of the window, and a Thursday application falls earlier in the dark. The clock gives you a clean line to configure, but the queue will be built from people borrowing on actual weekdays and weekends. You are deciding whether the hour of entry earns a fraud referral on its own, or needs to sit beside the other signals your team already weighs. The switch is still waiting.

Night applications show higher raw defaults

Start with the raw comparison, and keep the night rule off until you know what the difference represents. This is the same lender covered in the second-attempts case, with its name and products changed. Its book has about 310,000 current cash and revolving loans. Every client compared holds a current loan. Default is the lender’s own flag of payment difficulty on that loan, and a fraud loss and a credit loss look the same in it.

The first question is whether applications started between midnight and five in the morning default more often than the rest of the book.

Bar chart of current-loan default rates by application hour, with hours 5–7 above the whole-book rate of 8.1%
Default rates by application hour, highest at dawn and lowest in early evening

They do in the raw comparison: night applications defaulted at 9.6%, against 8.0% for the rest. The difference appears in both random halves and within each third of the outside score, so the hour looks like a candidate for review.

It is easy to turn that repeatable difference straight into a rule because the hour is simple to configure. The measured outcome is the lender’s payment-difficulty flag on a current loan, which combines fraud losses and credit losses. A raw-rate rule would refer clients on the basis of payment difficulty alone. Test what else is carried by the hour first.

Region explains the higher night default rate

A third of night applications came from the worst-rated region, compared with 14% of the book, and almost none came from the best-rated region.

Compare the distribution of application hours across regions before reading the night rate as a common signal.

Line chart compares application-hour shares by region, with the night period shaded from 0 to 5
Application hours cluster earlier in the worst rated region

Applications in the worst-rated region are concentrated several hours earlier than in the best-rated region. Treat the recorded hour as an approximate time whose clock reference is unspecified. The regional comparison shows how application timing varies across the book. It cannot establish whose clock the recorded hour represents.

Now compare night with the rate expected for the client’s region, outside score and product.

Night-started applications have higher default rates in every group, from 3.8% vs 3.0% high-score to 16.1% vs 15.2% low-score
Night and day default rates are nearly equal within regions

Night applications defaulted at 9.6% against 8.0% for the rest of the book, but the adjusted odds were 0.99 after region, score and product were held. Inside the middle region, night and day rates were almost the same. The regional mix accounts for the raw difference.

Teams often use the book-wide rate as the benchmark because it is easy to read and looks decisive. That sends people to review on information the region and score already carry. Compare each hour with its expected rate for region, score and product.

Evening and weekday patterns add little

The evening rate points down, and weekday rates sit close together. Both are reasons to check the other direction before keeping a clock rule.

Applications started from 17 to 20 defaulted at 6.7%, against 8.2% for the rest. The best-rated region contributes a larger share of later applications, and the evening rate falls toward the expected rate after region, score and product are held.

Teams can read a lower evening rate as evidence that the clock separates safer and riskier applications in both directions. Here, regional mix shifts across those hours, so judge the evening rate against its expected level after adjustment.

Check the weekday pattern and the hour-by-weekday cells as well.

Heatmap of current-loan default rates by weekday and start hour, with blank cells for fewer than 300 applications
Default rates by weekday and hour, with little weekday difference

Weekday rates stay close together, and the cells add little beyond the hour pattern. Many cells have too few applications for a firm reading. The book holds weekdays but no calendar dates, month or day of the month, so the month-end sales-quota pattern cannot be tested here.

Extra clock rules send more cases into review, but these comparisons add no useful basis for that work. Retire hour of day and weekday as referral checks on this book.

Earlier application history has a stronger pattern

The current application’s hour and the change in application hour across a client’s history add little after adjustment. Several earlier applications decided on one day carry a stronger pattern.

For clients with earlier applications, adjustment left little signal from night in the history or a large shift between application hours. A spread of twelve or more hours did survive, but it was rare. By contrast, clients with three or more earlier applications decided on one day defaulted at 9.8%, against 7.9% for the rest, and the pattern held in both halves.

Teams can read several same-day applications as independent attempts. In this book, these decision-day bursts mostly pass through the lender’s offices. They often include applications started, cancelled, refused or retyped on the same decision day. The record captures the decision day, which establishes the history pattern. The number of typing sessions remains unknown.

The spread of start hours within a burst adds little. A busy day that ended with no approval carries the stronger signal.

Bar chart: current-loan default rises from 7.5% with 1 earlier same-day application to 10.1% with 5 or more
Default rates rise with earlier same day application counts

The practical distinction is the history of decisions, especially a burst with no approval. Use the velocity analysis tool to test those history checks against your book, and keep decision-day counts separate from short-window counts.

Decisimo decision engine

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.

History counts separate default rates by score thirds

A count of four history checks separates default rates within each third of the outside score. The checks are three or more earlier applications decided on one day, a busiest day with two or more applications and no approval, a gap of thirty days or less since the latest earlier decision, and earlier applications started twelve or more hours apart.

The short-gap check is limited to the low-score third. The same-day pattern holds in every score third. When the four checks are counted together, default rates rise with the count in all three thirds, though the count adds only 0.001 to the area under the curve.

Kinds failedClientsLow scoreMiddleHigh score
072%14.2%5.9%2.9%
119%17.3%6.2%3.7%
2 or more8.7%18.8%7.1%3.9%

Teams can discard a check because its overall ranking gain looks small, or include every plausible time feature to make a rule look more complete. Here the count adds little ranking power, but it separates rates within score thirds. Keep the count for referral, and keep the short-gap result limited to the low-score third.

Count how many checks apply to each client, then validate the count in both random halves and inside each outside-score third.

Store night share fails the later loan test

The older-period test gives no basis for a store-level referral rule on this book. The share tracks the mix of clients using the store, including their region, and the pattern fails when tested against later loans.

Teams can rank stores by night share because a store list looks easy to act on. In the older-period test, raw differences changed after product and decision period were held, and none of the tested store patterns reached the stated significance threshold.

A store referral uses review capacity, so a pattern that fails against later performance gives the queue no reliable basis for prioritisation. Test any store-level time pattern on an older period and measure later loans, holding product and decision period constant, before acting on it.

Refer clients using the validated history count

Use the validated history count as the referral basis. Per 10,000 clients with earlier applications, a night rule refers about 250 clients and catches 2.9% of defaults. A rule for three or more earlier applications decided on one day refers about 1,600 and catches 19% of defaults. About 90% of the clients referred by that rule repaid.

The four history checks were compared with default outcomes, and the validated count supports referring clients for review. Set the outcome to referral, and keep the score and the other information in the decision.

The examples return to the applications in the opening scene and to Lee, whose afternoon application passes the score cutoff.

Refer whenReferredDefaultsRepaid
Night2502490%
Same day 3 or more1,60016090%
Time count 2 or more8709789%
Low score3,40052085%
Low score, same day 3 or more59010082%
Low score, time count 2 or more3606881%
Client examples show Dana defaulted, Sam repaid, and Lee failed three time checks after four same-day cancellations
Two night applicants and one daytime applicant separated by history checks

Dana’s Saturday application started at five in the morning, and Dana defaulted. Dana’s region and score already carried the night risk, and none of the history checks that held applied to Dana. Sam’s Thursday application started at four in the morning, and Sam repaid. Lee applied at two in the afternoon and passed the score cutoff, but four earlier applications had been decided on one day and all were cancelled. The history checks caught Lee.

  1. Compare the distribution of application hours across client regions. Use it to assess the regional mix a clock rule would capture.
  2. Compare each hour with its expected rate for the client’s region, outside-score third and product.
  3. Check the evening direction and weekday pattern. Retire night, evening and weekday referrals when these comparisons add no useful information.
  4. Move the test from the current application’s hour to the client’s earlier applications.
  5. Build four checks: three or more earlier applications decided on one day, a busiest day with two or more applications and no approval, a gap of thirty days or less, and earlier applications started twelve or more hours apart.
  6. Count the checks that apply. Validate the count in both random halves and inside each outside-score third, and keep the short-gap finding limited to the low-score third.
  7. Test any store-level time pattern on an older period against later loans, holding product and decision period constant.
  8. Refer clients with two or more checks for review, using the time count as a referral signal.

Questions about application time fraud checks

Should I refer night applications for fraud review?

Keep night-time as a referral trigger when an application arrives at an unusual hour for the channel or customer, then investigate identity, device and contact details before making a decision. Scripted attacks can submit batches overnight, so compare linked applications by device, phone, address and identity. Confirm that timestamps use a consistent clock and time zone across channels. A clock hour alone is a poor cutoff.

How should I investigate an application made at an unusual hour for that customer?

Compare the application time with the customer’s earlier applications using the same clock reference. If the hour is a sharp change, investigate mismatches in identity details, device history and contact information, and check whether those details link the application to other submissions. Treat the unusual hour as a reason to run those checks, not as a reason to decline the application.

What application-velocity windows and cutoffs should I test?

Start by testing rolling windows of 15 minutes, one hour and 24 hours. Count applications linked by phone, device, address or identity, including those cancelled, refused or retyped, then compare confirmed fraud found with legitimate applicants referred. Set cutoffs to fit review capacity, and keep short-window counts distinct from applications decided on the same day.

How should I check for a month-end fraud spike at a store or agent?

Compare application volume and confirmed fraud in the final days of each month with the same store’s or agent’s earlier periods. Hold product and decision period constant, then investigate linked identities, devices and contact details in any unusual rush. Sales pressure can drive a real spike, but changing applicant mix can create one too, so check later outcomes before using the pattern to prioritise referrals.

How do I validate a time-based fraud rule before putting it into review?

Set the cutoff using one period, then test it on later applications that were not used to choose the cutoff. Measure confirmed fraud referred, legitimate applicants referred and review volume, and compare results within score, region and product groups. The common mistake is to treat repayment difficulty as a fraud outcome. Keep the rule only if later fraud results justify the workload.

Decisimo decision engine

Put these checks into a decision flow

Create rules for credit, fraud or collections, then run them on live decisions.