| A | B | C | D | E | F | G | H | |
|---|---|---|---|---|---|---|---|---|
1 | Requirement ID # | Req Area # | Req Area Title | Requirement | Functional Clarifications | Solution Approach | External Data Source Used For Detection? | System Action |
2 | 6 | 1 | 1) Application Information Verification Scenarios | 1. Name and Date of Birth (DOB) Verification - 1.4 DOB Validity and Age Rules | Validate DOB is a real calendar date and applicant age falls within allowed business rules during the application submission workflow. | Backend validation to check DOB format and calculate applicant age from DOB. | No | Flag for Review |
3 | 7 | 1 | 1) Application Information Verification Scenarios | 1. Name and Date of Birth (DOB) Verification - 1.5 Duplicate Check Across Applications | Check whether the same applicant has previously submitted an application using matching or similar identity attributes. | Database search using identity attributes such as Name, DOB, and SSN to identify exact or near-duplicate applications. | No | Flag for Review |
4 | 12 | 1 | 1) Application Information Verification Scenarios | 3. Address Verification - 3.1 Address Reuse Detection | Detect repeated use of the same normalized address across multiple applications, including slight entry variations. | Normalize submitted address values and evaluate whether the same normalized address has been used across multiple recent applications. | No | Flag for Review |
5 | 13 | 1 | 1) Application Information Verification Scenarios | 3. Address Verification - 3.2 IP Geolocation Cross-Check | Compare applicant address geography against originating IP geography to identify major location inconsistencies. | Use IP geolocation lookup to compare the originating IP location against the submitted residential address and identify significant location mismatches. | Yes | Flag for Review |
6 | 15 | 1 | 1) Application Information Verification Scenarios | 3. Address Verification - 3.4 Detect if Address if For Sale or Recently Listed | Determine whether the submitted address appears to be actively listed for sale or recently sold/listed. | Integrate with a property data provider to evaluate listing status of the submitted and normalized address. | Yes | Flag for Review |
7 | 16 | 1 | 1) Application Information Verification Scenarios | 3. Address Verification - 3.5 Non-Residential or Commercial Address Detection | Determine whether the submitted address is residential versus commercial or otherwise non-residential. | Use address classification services to categorize the submitted address and identify non-residential or atypical address types. | Yes | Flag for Review |
8 | 17 | 1 | 1) Application Information Verification Scenarios | 3. Address Verification - 3.6 Address Normalization and Fuzzy Matching | Standardize submitted addresses into a consistent format and compare normalized values to detect near-duplicate addresses and suspicious reuse patterns. | Use address normalization to standardize submitted address values, then apply fuzzy comparison logic through the PeopleSoft Search Match API to identify closely matching addresses despite formatting or minor entry differences. | No | Flag for Review |
9 | 18 | 1 | 1) Application Information Verification Scenarios | 4. Phone Number Verification - 4.1 Disposable and VoIP Detection | Detect whether the submitted phone number is associated with a VoIP or disposable phone service. | Use a phone intelligence lookup service to determine phone number type and identify VoIP or disposable service indicators. | Yes | Flag for Review |
10 | 19 | 1 | 1) Application Information Verification Scenarios | 4. Phone Number Verification - 4.2 Carrier Lookup | Identify whether the submitted phone number is mobile, landline, prepaid, or otherwise associated with a higher-risk carrier or phone type. | Use a phone intelligence lookup service to retrieve carrier metadata and phone type classification. | Yes | Flag for Review |
11 | 20 | 1 | 1) Application Information Verification Scenarios | 4. Phone Number Verification - 4.4 Phone Number Reuse Detection | Detect repeated use of the same normalized phone number across multiple applications. | Normalize submitted phone numbers and evaluate reuse across historical application records. | No | Flag for Review |
12 | 21 | 1 | 1) Application Information Verification Scenarios | 5. Email Address Verification - 5.1 Disposable Email Detection | Identify whether the submitted email domain or address is disposable, temporary, or otherwise unsuitable for trusted registration. | Compare the submitted email domain against a maintained disposable-domain list and flag known disposable or temporary providers. Support an allowlist for legitimate domains and refresh the domain list regularly. | Yes | Flag for Review |
13 | 22 | 1 | 1) Application Information Verification Scenarios | 5. Email Address Verification - 5.2 Email Normalization and Duplicate Detection | Detect whether different submitted email variations resolve to the same underlying mailbox through provider-supported aliasing or formatting variations (e.g. Gmail addresses with a ".") | Apply provider-aware email normalization before duplicate and velocity checks and compare normalized email values to identify alias-based or near-duplicate mailbox usage. | No | Prevent Duplicate OAAP Account Creation / Flag for Review |
14 | 24 | 1 | 1) Application Information Verification Scenarios | 5. Email Address Verification - 5.4 Email Reputation Scoring | Assess whether the submitted email domain or address has suspicious characteristics or poor reputation. | Use an email intelligence provider to evaluate domain reputation and flag newly created, suspicious, or low-reputation email domains. | Yes | Flag for Review |
15 | 34 | 3 | 3) Data Source and Application Metadata Analysis | 1. External Data Source Validation - 1.3 Phone Carrier and Reputation Lookups | Validate phone number reputation and carrier metadata through an external source. | Use an external phone intelligence provider to return carrier, phone type, and risk-related indicators for the submitted phone number. | Yes | Flag for Review |
16 | 35 | 3 | 3) Data Source and Application Metadata Analysis | 1. External Data Source Validation - 1.4 Email Reputation and Domain Analysis | Validate email domain reputation and basic deliverability or risk characteristics through an external source. | Use an external email intelligence provider to evaluate the submitted email or domain and flag risky, disposable, or newly observed domains. | Yes | Flag for Review |
17 | 36 | 3 | 3) Data Source and Application Metadata Analysis | 1. External Data Source Validation - 1.5 IP Intelligence | Enrich submitted IP addresses with intelligence such as geolocation, ASN, hosting, proxy, and reputation indicators. | Use an external IP intelligence provider to retrieve country, state, city, ASN, proxy, hosting, and related risk indicators for the submitted IP address. | Yes | Flag for Review |
18 | 37 | 3 | 3) Data Source and Application Metadata Analysis | 3. Velocity and Duplication Detection - 3.1 Phone/Email Velocity Rules | Measure how frequently the same phone number, normalized email, or related identifiers are reused within short time windows to detect suspicious or automated account creation behavior. | Define configurable thresholds for repeated use of the same phone, normalized email, or related identifiers within rolling time windows. | No | Alert / Flag for Review / Optional Step-Up Verification / Optional Temporary Block |
19 | 38 | 3 | 3) Data Source and Application Metadata Analysis | 3. Velocity and Duplication Detection - 3.2 IP Address Velocity Rules | Measure registration and application activity concentration from the same IP address or subnet to detect suspicious bursts or automated account creation attempts. | Define configurable thresholds for repeated account creation or application activity from the same IP address or subnet within rolling time windows. | No | Alert / Throttle / Temporary Block / Flag for Review / Whitelist IPs for Exception |
20 | 39 | 3 | 3) Data Source and Application Metadata Analysis | 3. Velocity and Duplication Detection - 3.3 Device ID Fingerprinting | Identify repeated registrations or applications originating from the same device or browser fingerprint, even when IP address or email changes. | Capture browser and device-level signals to generate a device fingerprint and evaluate reuse across recent application or registration activity using configurable thresholds. | No | Flag for Review |
21 | 40 | 3 | 3) Data Source and Application Metadata Analysis | 4. IP Intelligence and Reputation Analysis - 4.1 Country Mismatch Detection | Identify whether the source IP country is inconsistent with expected applicant geography or business rules. | Use an external IP geolocation provider to compare the source IP country against the declared applicant country or approved operating regions and flag mismatches. Browser-based location (if available and permitted by the user) may be captured and used as a supplemental signal to improve location accuracy. This signal shall be optional, non-blocking, and used only to enhance fraud evaluation. | Yes | Flag for Review |
22 | 41 | 3 | 3) Data Source and Application Metadata Analysis | 4. IP Intelligence and Reputation Analysis - 4.2 Known Proxy/VPN Detection | Detect whether the originating IP address is associated with a known proxy, VPN, TOR, or other anonymization service. | Use an external IP intelligence provider to identify anonymization indicators such as VPN, proxy, TOR, or hosting services and flag known anonymized connections. | Yes | Flag for Review |
23 | 42 | 3 | 3) Data Source and Application Metadata Analysis | 4. IP Intelligence and Reputation Analysis - 4.3 IP Risk Scoring | Assign an IP risk score based on proxy, VPN, hosting, reputation, and abuse indicators. | Use an external IP intelligence provider to retrieve IP risk indicators and map them into configurable OAAP risk score bands such as low, medium, or high risk. | Yes | Flag for Review - In Phase 1, high-risk IPs shall contribute to overall fraud scoring and review decisions but shall not automatically block application submission. |
24 | 44 | 3 | 3) Data Source and Application Metadata Analysis | 5. Application Metadata Analysis and Scoring - 5.2 Explainability | Provide understandable explanations for why an application received a given set of fraud flags or review indicators. | Expose top contributing indicators and mapped reason codes to staff and avoid black-box-only flagging logic. | No | Informational Only - Store and display flagged indicators in OAAP including reviewer-readable explanations of the indicators and controls that contributed to the result. |
25 | 50 | 4 | 4) Risk Scoring & Indicators | 3. Reason Codes and Flags Generation - | Generate clear, standardized reason codes and flags that explain why an application was flagged for fraud review or identified as potentially suspicious. | Use standardized reason codes derived from internal rule outcomes and external enrichment results, and allow multiple flags to be generated for a single application. | No | Informational Only - Standardized application-level fraud reason codes and review flags derived from all triggered controls. |
26 | 53 | 4 | 4) Risk Scoring & Indicators | Service Indicator Integration | Create and apply a PeopleSoft operational service indicator when an application meets approved fraud review criteria. | Use internal OAAP rule outcomes and reason codes to determine when a service indicator should be created and transmitted to PeopleSoft. | No | Informational Only - The integration shall send the approved service indicator and OAAP fraud control reason codes in the Comment field. |
27 | 54 | New | New | Account Activated event– Include in Audit Logs | Capture OAAP account activation events, including source IP address and key event details, for audit, monitoring, and investigation purposes. | Integrate with Okta event hooks and system logs to capture account activation events and persist them in the OAAP logging store. | Yes (Okta) | Informational Only - Store and display details for OAAP Account Activation events in the OAAP Audit Logs |
28 | 55 | 3 | 3) Data Source and Application Metadata Analysis | Phone Not Verified | Verify whether the submitted phone number has been successfully verified through OTP or equivalent verification mechanism. | Use internal verification status from OAAP (OTP / verification flow). | No | Flag for Review |
29 | 56 | 3 | 3) Data Source and Application Metadata Analysis | Browser Location Not Provided | Detect whether browser-based geolocation data is available for the applicant. | Capture browser geolocation (if user permission is granted) and flag when not available. | No | Flag for Review |