Engineering Vehicle Fraud Checks as Point-of-Sale Transaction Gates

A point-of-sale fraud check sits in the transaction path. This article shows how to define its deadline, state model, latency budget, verdict policy, failure behaviour and audit evidence. The check must return before the finance decision or follow an explicit deadline policy.

A check that misses the transaction deadline cannot control the transaction without a defined fallback.

The framework also applies these criteria to the reported MotorVerify design. The product assessment remains limited because the supplied material contains no attributed documentation, engineering testimony, observed traces or performance measurements.

Product assessment

The draft reports the following MotorVerify capabilities. The supplied material does not independently confirm them.

Reported capability	Evidence needed
Guided video capture at the point of sale	Product documentation, engineering testimony or an observed capture trace
Vision models that assess whether a vehicle is real and physically present	Model description and observed processing trace
Detection of screen replays and printed photographs	Anti-spoofing documentation and validation evidence
Cross-references to DVLA and MOT records	Dependency documentation and observed request traces
Assessment of more than 60 data points	Representative categories and their roles in the decision
Parallel execution of checks	Architecture description and component timing trace
Streaming of partial results	Interface documentation and observed event trace
Timestamped storage of each data point	Data model, retention policy and audit controls
Pass, Refer or Fail verdicts	Approved definitions, aggregation rules and transaction consequences

The reported design is plausible as a transaction-gate pattern. The available material does not establish that MotorVerify implements this pattern or meets point-of-sale timing and decision-quality requirements.

The transaction-gate model

A gate begins when the inspection starts and ends when a transaction outcome becomes available. Its design must cover capture, request validation, queueing, checks, evidence aggregation and verdict publication.

Capture
  |
  v
Validate request -----> Reject invalid request
  |
  v
Queue work
  |
  +----------+-------------+
  |          |             |
Vision   Anti-spoofing   Record lookup
  |          |             |
  +----------+-------------+
             |
       Aggregate evidence
             |
      Pass / Refer / Fail
             |
   Proceed / Review / Stop

The nominal flow is not enough. The design must also define:

• Which checks can start during capture.
• Which checks require complete capture.
• Dependencies between vision, anti-spoofing and record checks.
• Queue boundaries and maximum queueing time.
• Evidence required for each verdict.
• Whether partial results affect a verdict or only report progress.
• Timeout and retry rules for external requests.
• Treatment of cancellation, duplication, late completion and stale evidence.

Request states

A compact state model makes terminal outcomes explicit.

                 +----------------+
                 |     Queued     |
                 +----------------+
                    |          |
               start|          |cancel
                    v          v
              +-----------+  +-----------+
              |  Running  |  | Cancelled |
              +-----------+  +-----------+
                |    |   |
       complete |    |   | deadline expires
                |    |   v
                |    | +-----------+
                |    | | Timed out |
                |    | +-----------+
                |    |
                |    | cancel
                |    v
                | +-----------+
                | | Cancelled |
                | +-----------+
                v
          +-------------+
          |  Completed  |
          +-------------+

Cancelled, Timed out and Completed are terminal request states unless a documented policy permits another transition. A late component result must not silently move a cancelled or timed-out request into Completed.

Duplicate submissions need stable request identities and idempotency rules. The policy must state whether a duplicate returns the existing state or creates separate work.

Latency budget

The point-of-sale deadline must be defined before feasibility can be assessed.

Let:

• D be the maximum permitted time from inspection start to transaction decision.
• C be guided capture time.
• Q be queueing time.
• V be vision-model processing time.
• S be anti-spoofing processing time.
• R be vehicle-record lookup time, including permitted retries.
• A be aggregation and verdict-publication time.

If processing starts after capture and the three checks run concurrently:

Total latency = C + Q + max(V, S, R) + A
Requirement:   Total latency <= D

If checks start during capture, the overlap must be measured rather than assumed:

Total latency = elapsed time from capture start
                to publication of the transaction verdict

Requirement: Total latency <= D

Parallel execution can reduce elapsed time. It does not guarantee an earlier verdict. The slowest mandatory check, queueing delay, retries and aggregation policy still determine completion time.

Streaming partial results improves progress visibility. It reduces decision latency only when the aggregation policy permits a valid verdict before all checks finish.

Measurement boundaries

Boundary	Starts	Ends	Required evidence
Capture	Inspection begins	Required media is accepted	Timestamped capture trace and completion criteria
Queueing	Work is submitted	Processing starts	Queue-delay percentiles
Model processing	Model work starts	Required outputs are available	Per-check latency percentiles
External lookup	Request is issued	Accepted response or terminal timeout	Lookup, timeout and retry measurements
Aggregation	Inputs are available or expire	Verdict is published	Aggregation latency and decision trace
End to end	Inspection begins	Transaction outcome is available	Latency percentiles against D

A hypothetical deadline path

Consider a request where vision and anti-spoofing finish but the vehicle-record lookup does not return. This is a design example, not observed MotorVerify behaviour.

The outcome depends on policies defined before deployment:

1. The retry policy decides whether another lookup attempt is permitted.
2. The deadline policy decides whether that retry can fit within D.
3. The aggregation policy decides whether the completed checks support any verdict.
4. The verdict policy maps the available evidence to Pass, Refer, Fail or another permitted outcome.
5. The transaction policy decides whether the finance process proceeds, pauses or stops.

If the record lookup is mandatory for Pass, the system cannot return Pass because the dependency timed out. It must follow the approved timeout path. A timeout must not become an implicit pass.

Latency therefore cannot be assessed separately from verdict policy.

Request trace

A sourced end-to-end trace is required to test the reported architecture. The supplied material does not include one.

At minimum, the trace should record:

request_id
inspection_started_at

capture_accepted_at
work_queued_at
processing_started_at

external_request_issued_at
external_retry_issued_at
external_response_or_timeout_at

evidence_aggregated_at
verdict_published_at

transaction_deadline_at
request_state
final_verdict
verdict_reason
transaction_action

Policy decisions attach to specific points in the trace:

inspection_started_at
  |
  |-- Deadline D begins
  v
capture_accepted_at
  |
  v
work_queued_at
  |
  |-- Queueing limit applies
  v
processing_started_at
  |
  +-- Internal checks
  |
  +-- External request
        |
        |-- Timeout policy applies
        |-- Retry policy applies
        |-- Retry must remain within D
        v
external_response_or_timeout_at
  |
  |-- Aggregation policy selects usable evidence
  |-- Staleness and conflict rules apply
  v
evidence_aggregated_at
  |
  |-- Pass / Refer / Fail definition applies
  v
verdict_published_at
  |
  |-- Transaction policy maps verdict to action
  v
transaction_action

The trace must identify mandatory checks, retry attempts, state transitions and the evidence used for the verdict. Success traces alone are insufficient. Timeout, cancellation, duplicate and late-completion paths also require observation.

Verdict policy

Pass, Refer and Fail need approved operational definitions. These definitions can specify transaction behaviour without exposing detection thresholds or other sensitive controls.

Path	Policy to define	Evidence needed
Pass	Whether the transaction proceeds and which checks must complete	Aggregation rule and complete decision trace
Refer	Whether the transaction pauses, who reviews it and how the review ends	Review procedure, routing record and reviewer outcome
Fail	Whether the transaction stops and what evidence is retained	Stop policy and retained decision record
Deadline missed	Whether the request refers, stops or takes another defined path	Deadline policy and timeout trace
External timeout	Retry limit, permitted verdicts and degraded behaviour	Dependency trace and aggregation record
Duplicate request	Deduplication and idempotency behaviour	Request identifiers and state-transition record
Cancellation	Which work stops and what record remains	Cancellation trace across each component
Stale result	Validity period and recheck policy	Result age and policy decision
Conflicting evidence	Precedence, referral or stop rule	Input evidence and aggregation explanation
Customer departure	Whether processing continues and the transaction remains blocked	Session state and recorded outcome

Rates derived from these paths require a defined evaluation population and period. False-positive and false-negative rates also require an agreed reference outcome.

Failure behaviour

Retries can extend the critical path and create duplicate external requests. The design must define retryable failures, maximum attempts, delays between attempts and the outcome after retry capacity is exhausted.

Cancellation can occur while work is queued, running or waiting on an external dependency. The cancellation policy must state:

• Whether queued work is removed.
• Whether active internal work stops.
• Whether external calls can be cancelled.
• Whether late results are discarded or retained.
• Whether a late result can alter the terminal request state.

Captured media and record responses must represent the same decision point. Validity periods and recheck rules prevent old evidence from being reused without an explicit decision.

Conflicting evidence requires a deterministic path. The aggregation policy must state whether a conflict produces Refer, Fail or another permitted outcome.

Audit evidence

Timestamps support later investigation. They do not establish audit integrity on their own.

The design needs documented controls for:

• Retention periods.
• Access authorisation.
• Protection against alteration.
• Links between requests, evidence, retries and verdicts.
• Records of cancellation, late completion and state changes.

Evidence needed for a product conclusion

A product-specific assessment requires:

• Attributed documentation or testimony for each reported capability.
• A point-of-sale deadline supported by dealership workflow evidence.
• End-to-end and component latency percentiles under representative load.
• Observed traces for success, timeout, retry, cancellation, duplication and late completion.
• Approved definitions and transaction consequences for Pass, Refer and Fail.
• Decision-quality measurements using defined populations and reference outcomes.
• Representative categories and decision roles for the reported 60-plus data points.
• Documented retention, access-control and alteration-protection mechanisms.

What this means

A point-of-sale check can gate a transaction only when its deadline, state transitions, mandatory evidence, verdict consequences and failure paths are explicit. This framework defines how to assess that gate, but the supplied material does not support a conclusion about MotorVerify’s implementation or performance.

---

Originally published at AFT Group Engineering Insights.