Version: 2.0 | Status: Ready for Stakeholder Review | Date: 2026-01-15
Change Log
| Version | Date | Author | Changes |
|---|
| 1.0 | 2026-01-09 | Product Team | Initial technical draft |
| 2.0 | 2026-01-15 | Product Team | Business-focused conversion: measurable outcomes, success metrics, consolidated requirements |
1. Executive Summary
1.1 Purpose
Enable rental companies to protect their business by identifying and flagging high-risk clients, preventing repeat offenders from causing additional losses through fraud, vehicle damage, or payment defaults.
1.2 Problem Statement
Rental companies lose an estimated 2-5% of annual revenue to problematic clients who damage vehicles, fail to pay, or commit fraud. Without a centralized blacklist system:
- Operators rely on memory or manual records, allowing repeat offenders to slip through
- Problematic clients switch between rental companies on the platform undetected
- Companies cannot share risk intelligence, multiplying losses across the ecosystem
1.3 Business Value
| Value Area | Measurable Outcome | Target | Timeframe |
|---|
| Loss Prevention | Reduce revenue loss from problematic clients | 50% reduction in repeat-offender incidents | 6 months post-launch |
| Fraud Reduction | Decrease fraud-related write-offs | 30% fewer fraudulent transactions | 12 months |
| Cross-Tenant Protection | Prevent platform-wide repeat offenders | 80% of blacklisted clients detected when switching companies | 6 months |
| Operational Efficiency | Reduce manual record-keeping time | 5 hours/week saved per operator | 3 months |
| Compliance | Maintain GDPR-compliant risk management | Zero data privacy violations | Ongoing |
1.4 Target Users
| Role | Access Level | Primary Benefit |
|---|
| Admin | Full management (add/remove/override) | Protect company from high-risk clients |
| Operator | Add clients, view warnings | Receive real-time alerts before booking problematic clients |
| Driver | No access | N/A |
2. Success Metrics
| Metric | Definition | Baseline | Target | Measurement Method | Timeline |
|---|
| Repeat Offender Rate | % of incidents from previously problematic clients | Current incident logs | -50% | Incident tracking with client history cross-reference | 6 months |
| Fraud Loss Amount | Monthly write-offs from fraudulent clients | Accounting records | -30% | Financial reporting integration | 12 months |
| Cross-Tenant Detection Rate | % of blacklisted clients caught when switching companies | 0% (no system exists) | 80% | TRA Guard match logs | 6 months |
| Operator Time Savings | Hours spent on manual client verification | Time study baseline | -5 hrs/week/operator | Workflow time tracking | 3 months |
| Warning Response Time | Time from data entry to blacklist warning display | N/A | <1 second | System performance monitoring | Launch |
| Data Privacy Compliance | GDPR violations related to blacklist data | 0 | 0 | Compliance audit quarterly | Ongoing |
| Operator Adoption | % of operators actively using TRA Guard | 0% | 90% | Usage analytics | 3 months |
3. User Stories
3.1 Admin User Stories
| Priority | User Story | Acceptance Criteria |
|---|
| P0 | As an admin, I can mark a client as blacklisted so they cannot easily rent again | GIVEN a client profile, WHEN I enable blacklist status and save, THEN the client is flagged immediately and appears in global blacklist (if birthdate present) |
| P0 | As an admin, I can remove blacklist status to restore a client’s booking privileges | GIVEN a blacklisted client, WHEN I disable blacklist status, THEN the flag is removed from both tenant and global lists |
| P1 | As an admin, I can see who blacklisted a client and when for accountability | GIVEN a blacklisted client, WHEN I view their profile, THEN I see the user who flagged them and the timestamp |
| P1 | As an admin, I can override blacklist warnings to allow specific bookings when justified | GIVEN a blacklist warning, WHEN I proceed with booking anyway, THEN the system allows it while logging the override |
| P2 | As an admin, I can view the platform-wide global blacklist to understand ecosystem risk | GIVEN admin access, WHEN I access global blacklist view, THEN I see all cross-tenant blacklisted clients |
3.2 Operator User Stories
| Priority | User Story | Acceptance Criteria |
|---|
| P0 | As an operator, I receive a visual warning when entering a blacklisted client’s information | GIVEN the Add Client form, WHEN I enter name/surname/birthdate matching a blacklisted person, THEN TRA Guard displays a red warning within 1 second |
| P0 | As an operator, I can mark problematic clients as blacklisted to prevent future issues | GIVEN a client who caused problems, WHEN I enable blacklist checkbox and save, THEN the client is flagged for my company (and globally if birthdate exists) |
| P1 | As an operator, I see a clear “all clear” indicator when a client has no blacklist history | GIVEN the Add Client form, WHEN I enter information for a clean client, THEN TRA Guard displays a green checkmark confirmation |
| P2 | As an operator, I can add notes explaining why a client was blacklisted | GIVEN the blacklist action, WHEN I flag a client, THEN I can optionally add a reason for future reference |
4. Functional Requirements
4.1 Blacklist Management
| Requirement | Business Outcome | Success Measure |
|---|
| System must allow authorized users to flag clients as blacklisted | Problematic clients are identified and tracked | 100% of flagged clients visible in tenant blacklist |
| System must maintain a global blacklist accessible across all tenants | Platform-wide protection from repeat offenders | Cross-tenant detection rate >80% |
| Global blacklist entries require name, surname, and birthdate for accurate matching | Minimize false positives while enabling cross-tenant detection | <1% false positive rate |
| Tenant-only blacklisting available when birthdate is missing | Flexibility to flag clients with incomplete data | All clients can be flagged regardless of data completeness |
4.2 Real-Time Warning System (TRA Guard)
| Requirement | Business Outcome | Success Measure |
|---|
| System must check client information against global blacklist in real-time | Operators warned before booking problematic clients | Warning displayed within 1 second of data entry |
| Warning must clearly indicate blacklist status without blocking the booking | Informed decision-making while maintaining operator flexibility | 100% of warnings acknowledged, override logged |
| System must display “clear” confirmation when no blacklist match found | Operator confidence in new client bookings | Clear status visible for all non-blacklisted clients |
4.3 Audit & Compliance
| Requirement | Business Outcome | Success Measure |
|---|
| All blacklist actions must be logged with user and timestamp | Accountability and audit trail | 100% of actions traceable |
| Blacklist data limited to name, surname, birthdate only | GDPR compliance through data minimization | Zero privacy violations |
| System must support right-to-erasure requests | Regulatory compliance | Deletion completed within 30 days of valid request |
4.4 Integration Requirements
| Requirement | Business Outcome | Success Measure |
|---|
| Blacklist status must sync with search indexes for filtering | Operators can filter client lists by blacklist status | Real-time index updates |
| Blacklist changes must trigger webhooks for external system notifications | Partner systems stay synchronized | Webhook delivery within 5 seconds |
| Billion marketplace sync must include blacklist status | Consistent risk management across channels | 100% sync accuracy |
5. Business Rules
5.1 Data Requirements
- Global blacklist entry requires: name + surname + birthdate (all three)
- Tenant blacklist can be set with any available client data
- Matching uses exact strings on normalized data (case-sensitive, YYYY-MM-DD date format)
5.2 Access Control
| Action | Admin | Operator | Driver |
|---|
| Add to blacklist | ✓ | ✓ | ✗ |
| Remove from blacklist | ✓ | ✓ | ✗ |
| View blacklist status | ✓ | ✓ | ✗ |
| Override warnings | ✓ | ✗ | ✗ |
| View global blacklist | ✓ | ✗ | ✗ |
5.3 Operational Rules
- Blacklist is a warning system, not a hard block—operators can proceed with informed judgment
- No automatic expiration—blacklist status persists until manually removed
- All tenants can see global blacklist entries via TRA Guard (privacy-preserving: shows warning, not source)
6. Dependencies
6.1 Upstream Dependencies
| Dependency | Impact | Risk Mitigation |
|---|
| Multi-Tenant Architecture (PRD-01) | Tenant isolation for blacklist data | Required before launch |
| Authentication & Authorization (PRD-02) | Role-based access control | Required before launch |
| Client Management (PRD-04) | Client data model integration | Required before launch |
6.2 Downstream Impact
| System | Integration | Priority |
|---|
| Orders & Reservations (PRD-06) | Future: blocking/warning at order creation | P2 enhancement |
| Communications (PRD-10) | Admin notifications for blacklist attempts | P2 enhancement |
7. Non-Functional Requirements
| Category | Requirement | Target | Measurement |
|---|
| Performance | Blacklist check response time | <100ms | API monitoring |
| Performance | TRA Guard UI update time | <1 second (500ms debounce + query) | User analytics |
| Scalability | Global blacklist capacity | 100,000+ entries | Database metrics |
| Reliability | Blacklist operation success rate | 99.9% | Error tracking |
| Availability | Graceful degradation if service unavailable | Skip check, log error, allow booking | Incident monitoring |
| Security | Audit trail completeness | 100% of actions logged | Compliance audit |
8. Glossary
| Term | Definition |
|---|
| Blacklist | List of clients restricted from future rentals due to problematic behavior |
| Tenant-Level Blacklist | Blacklist status visible only within the company that flagged the client |
| Global Blacklist | Cross-tenant blacklist shared across all platform companies |
| TRA Guard | ”Trust and Risk Assessment” - real-time blacklist warning component |
| GDPR | General Data Protection Regulation (EU privacy law) |
9. Open Questions
- Override logging—should overrides require reason text?
- Blacklist expiration—should we add optional auto-expire after N years?
- Severity levels—differentiate between fraud vs. payment issues vs. minor violations?
- Dispute process—how do clients contest blacklist status?
- Cross-tenant visibility—show source company to admins, or always anonymous?
Document Status: Ready for Stakeholder Review
Next Steps: Business stakeholder approval → Technical estimation → Implementation planning
Owner: Product Team
Reviewers: [To be assigned]