Problem Description

You are tasked with building a fraud-screening validator that processes transaction data from a CSV file and generates a human-readable report. The validator must apply a series of risk rules and user behavior matching logic, then output a prioritized list of specific error codes for suspicious transactions.

Input Data

1. Transactions CSV

Each row in the CSV represents a single transaction and contains exactly six fields:

• transaction_id (string)
• user_id (string)
• timestamp (string, assumed to be in ISO-8601 format, e.g., 2026-01-22T13:45:00Z)
• amount (string, which must be parseable as a decimal number)
• country (string, e.g., US)
• payment_method (string, e.g., VISA, PAYPAL) The first row of the CSV should be treated as a header and skipped.

2. Risk Configuration

This configuration defines global risk parameters:

• min_amount: The minimum allowed transaction amount (inclusive).
• max_amount: The maximum allowed transaction amount (inclusive).
• blocked_payment_methods: A collection (set/list) of payment methods that are not permitted.

3. User Behavior Baseline

For each user_id, a baseline profile is provided with three behavioral features:

• usual_countries: A collection (set/list) of countries where the user commonly transacts.
• usual_time_buckets: A collection (set/list) of predefined time-of-day buckets (e.g., NIGHT, MORNING, AFTERNOON, EVENING) when the user commonly transacts.
• usual_amount_range: An inclusive range [low, high] representing the user's typical transaction amounts. You may assume that every user_id present in the transaction file will have a corresponding entry in the baseline data.

Processing Rules

Part 1: Verify Transaction Data Integrity

For every transaction, ensure that all six fields are non-empty after trimming any leading or trailing whitespace.

Part 2: High-Risk Rule Validation

In addition to Part 1, a transaction is flagged as suspicious if either of the following conditions is met:

• Amount Rule: The amount is outside the [min_amount, max_amount] range, or the amount string cannot be successfully parsed into a decimal number.
• Payment Method Rule: The payment_method is included in the blocked_payment_methods list.

Part 3: User Behavior Matching

Calculate how well a transaction aligns with the user's established behavioral baseline across the three specified features.

1. Feature Extraction / Normalization: Convert the transaction's timestamp into one of the defined usual_time_buckets. You must clearly define the rules for this time bucketing (e.g., specific hour ranges for MORNING, AFTERNOON, etc.).
2. Matching: Determine if each of the following features matches the user's baseline:
   • country: Matches if it is present in usual_countries.
   • time_bucket: Matches if it is present in usual_time_buckets.
   • amount: Matches if it falls within usual_amount_range.
3. Match Ratio: Compute match_ratio = (number of matched features) / 3. If match_ratio < 0.5, the transaction should be flagged as suspicious due to behavior mismatch.

Part 4: Smart Fraud Error Reporting

Instead of a generic SUSPICIOUS status, output specific error codes. Adhere to the following rules:

• Output a maximum of two error codes per transaction.
• Error codes must be chosen based on the following priority order (highest priority first):
  1. MISSING_FIELD
  2. AMOUNT_OUT_OF_RANGE
  3. BLOCKED_PAYMENT_METHOD
  4. BEHAVIOR_MISMATCH
• If a transaction has no errors, output OK.

Output Format

Produce a report with fixed-width and aligned columns for enhanced readability. The report must, at minimum, include:

• transaction_id
• user_id
• result (This field will contain either OK or up to two comma-separated error codes).

Constraints

• The implementation must be efficient enough to process a large number of rows. Streaming processing is an acceptable approach.
• The time bucketing rules for timestamp to usual_time_buckets must be explicitly defined within the code.
• Whitespace trimming is mandatory when checking for empty fields.