PII, Fraud, And Underwriting Event Processing

What's being tested

These problems test set-based deduplication, event-stream processing, field validation, and preserving temporal order. You must distinguish underwriting events from fraud flags, normalize eligible values, and update shared state at the correct point in processing.

Patterns & templates

• Use a global set for distinct nonempty PII values; membership and insertion are expected O(1) average, with O(U) space for U unique values.

• Iterate events once in input order; maintain state incrementally rather than rescanning prior events, yielding O(E × F) time for E events and F fields.

• Centralize recognized-field handling with an allowlist such as {"address", "phone", "email", "ssn"}; ignore unknown keys explicitly.

• Normalize only as specified: exclude null, missing, and empty-string values, but do not silently alter formatting unless the prompt requires it.

• For fraud propagation, check an underwriting event’s PII against the suspicious set before adding its values; ordering changes the result.

• Separate event classification from value extraction with helpers like is_underwriting(event) and extract_pii(event) to reduce branching and testing complexity.

• Preserve original event order; sorting can violate causality and incorrectly allow later fraud information to affect earlier underwriting decisions.

Common pitfalls

Pitfall: Counting fields or events instead of globally distinct values; the same email appearing repeatedly contributes only once.

Pitfall: Marking an underwriting event suspicious after inserting its own PII, which incorrectly makes self-introduced values trigger fraud.

Pitfall: Treating fraud flags as ordinary PII sources, or allowing missing, empty, and unrecognized fields into the set.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.