diff --git a/functional_tests/README.md b/functional_tests/README.md index 1c972b2..9e596e1 100644 --- a/functional_tests/README.md +++ b/functional_tests/README.md @@ -65,3 +65,20 @@ --- +**Execution Date:** 4/30/2026, 3:30:17 PM + +**Test Unique Identifier:** "ZBIO-5213" + +**Input(s):** + 1. JIRA ID: ZBIO-5213 + +**Test Output Folder:** + 1. [ZBIO-5213.json](ZBIO-5213/ZBIO-5213.json) + 2. [ZBIO-5213.feature](ZBIO-5213/ZBIO-5213.feature) + 3. [ZBIO-5213.csv](ZBIO-5213/ZBIO-5213.csv) + 4. [ZBIO-5213.xlsx](ZBIO-5213/ZBIO-5213.xlsx) + 5. [ZBIO-5213.docx](ZBIO-5213/ZBIO-5213.docx) + 6. [ZBIO-5213.yaml](ZBIO-5213/ZBIO-5213.yaml) + +--- + diff --git a/functional_tests/ZBIO-5213/.roost/roost_metadata.json b/functional_tests/ZBIO-5213/.roost/roost_metadata.json new file mode 100644 index 0000000..e3f411d --- /dev/null +++ b/functional_tests/ZBIO-5213/.roost/roost_metadata.json @@ -0,0 +1,19 @@ +{ + "project": { + "name": "ZBIO-5213", + "created_at": "2026-04-30T10:00:17.091Z", + "updated_at": "2026-04-30T10:00:17.091Z" + }, + "files": { + "input_files": [ + { + "fileName": "ZBIO-5213.txt", + "fileURI": "/var/tmp/Roost/RoostGPT/demo-functional-test_clone/1777542707/functional_tests/ZBIO-5213/ZBIO-5213.txt", + "fileSha": "0e017aaae1" + } + ] + }, + "api_files": { + "input_files": [] + } +} \ No newline at end of file diff --git a/functional_tests/ZBIO-5213/ZBIO-5213.csv b/functional_tests/ZBIO-5213/ZBIO-5213.csv new file mode 100644 index 0000000..f32566b --- /dev/null +++ b/functional_tests/ZBIO-5213/ZBIO-5213.csv @@ -0,0 +1,30 @@ +"Automated Credit Card Due Reminder Notification – Masking & Audit Compliance" +"Overdue Balance Alert with State Transition – Masking Branch Coverage" +"Collection Notification Trigger at Delinquency Boundary with Fee Calculation" +"Collection Agency Data Hand-Off via Secure API – Masked Integration & Error Handling" +"Collection Agency Escalation at Policy Day Threshold with Error Handling" +"Full Credit Card Collection Lifecycle from Reminder to Legal Action" +"Regulatory Audit Trail Verification across All Collection Lifecycle Events" +"Audit and Masking Validation during External Document Generation for Collection Agency and Legal Partners" +"Cross-Account Data Integrity and State Transition" +"Lifecycle Interruption and Recovery After System Outage with Masking Assurance" +"PII Masking Failure and Notification Transmission Exception Handling" +"Unauthorized Access Attempt and Cross-Account Data Leakage Prevention" +"Payment Plan Enrollment Failure and Error Notification" +"Payment Plan Terms Violation Without Legal Escalation" +"Partial Payment Plan Acceptance and Workflow Handling Variations" +"Collection Notification with Dynamic Overdue Amount Adjustment" +"Legal Action Documentation Generation and Transmission with Card Masking Enforcement" +"Payment Plan Proposal Timing and Compliance with Masking Enforcement" +"Multi-Channel Notification Content Verification and Role-Specific Masking" +"Payment Due Reminder Timing & Duplicate Suppression – Masking Compliance" +"Dynamic Due Date Adjustment and Notification Window Compliance" +"Multi-Channel Opt-In/Opt-Out Management for Collection Communications" +"Real-Time Notification Retry and Failure Recovery Mechanism Verification" +"Escalation and De-Escalation State Transition with Masking Enforcement" +"Cardholder Accepts Custom Payment Plan via Self-Service Portal" +"User Requests Detailed Breakdown of Collection Fees and Charges via Portal" +"Accessibility and Usability Verification of Collection Notifications and Portal Flows" +"Peak Load Performance Test for Bulk Collection Notification Dispatch" +"Formal Collection Notification and Payment Plan Proposal with Masked Card Number & Branch Coverage" +"User-Initiated Escalation Request and Immediate Agency/Legal Notification" \ No newline at end of file diff --git a/functional_tests/ZBIO-5213/ZBIO-5213.docx b/functional_tests/ZBIO-5213/ZBIO-5213.docx new file mode 100644 index 0000000..9e4c7d9 Binary files /dev/null and b/functional_tests/ZBIO-5213/ZBIO-5213.docx differ diff --git a/functional_tests/ZBIO-5213/ZBIO-5213.feature b/functional_tests/ZBIO-5213/ZBIO-5213.feature new file mode 100644 index 0000000..07c9404 --- /dev/null +++ b/functional_tests/ZBIO-5213/ZBIO-5213.feature @@ -0,0 +1,393 @@ +Feature: Credit Card Collection Workflow – Masking, Compliance, Audit & Integration + + # Background for API and workflow tests + Background: + Given the API base URL is set + And audit and masking enforcement are enabled + And user authentication is available for cardholder, agency, legal staff, and administrator roles + + # API Workflow & Masking Tests + @api + Scenario Outline: Automated Credit Card Due Reminder Notification – Masking & Audit Compliance + Given a cardholder account "" with next payment due in days and no prior reminders in window + When system triggers due reminder notification job + Then notification is delivered to cardholder via "" containing only last 4 digits "" of card "" + And notification payload does NOT expose full or partial card number (only last 4 digits) + And notification includes correct due date "", amount "", and cardholder name "" + And audit log records notification event, cardholder role, and masking compliance + + Examples: + | account_id | card_number | last_4 | due_in_days | channel | due_date | due_amount | cardholder_name | + | 12345 | 4012888888881881 | 1881 | 5 | email | 2024-07-15 | $500.00 | Alice Smith | + | 67890 | 5555555555554444 | 4444 | 7 | sms | 2024-07-17 | $1000.00 | Bob Johnson | + + @api + Scenario Outline: Overdue Balance Alert with State Transition – Masking Branch Coverage + Given a credit card account "" with payment due date and payment status "" + When due date passes and system triggers overdue processing + Then overdue alert is sent ONLY if payment is "" + And alert includes only last 4 digits "" of card "" + And overdue amount "" and consequences are correct per payment variation + And event/state change are recorded in audit log + + Examples: + | account_id | card_number | last_4 | due_date | payment_status | alert_status | overdue_amount | + | 12345 | 4012888888881881 | 1881 | 2024-07-15 | unpaid | sent | $500.00 | + | 67890 | 5555555555554444 | 4444 | 2024-07-15 | partial | sent | $200.00 | + | 24680 | 4111111111111111 | 1111 | 2024-07-15 | late_full | not_sent | $0.00 | + + @api + Scenario Outline: Collection Notification Trigger at Delinquency Boundary with Fee Calculation + Given credit card "" is overdue for "" days + When system triggers collection notification processing + Then collection notification is sent only when delinquency threshold "" is reached + And notification includes overdue amount "", late fee "", and only last 4 digits "" of card "" + And audit log records the event and fee computation + And no full card number appears in any notification or log + + Examples: + | card_id | card_number | last_4 | overdue_days | trigger_days | overdue_amount | late_fee | + | 12345 | 4012888888881881 | 1881 | 29 | 30 | $500.00 | $0.00 | + | 12345 | 4012888888881881 | 1881 | 30 | 30 | $510.00 | $10.00 | + | 67890 | 5555555555554444 | 4444 | 31 | 30 | $1020.00 | $20.00 | + + @api + Scenario Outline: Collection Agency Data Hand-Off via Secure API – Masked Integration & Error Handling + Given delinquent account "" eligible for agency escalation and agency endpoint "" + When system prepares and transmits data package: + """ + { + "balance_due": "", + "cardholder_name": "", + "last_4_digits": "" + } + """ + to agency API endpoint "" + Then agency system receives masked data and acknowledges receipt + And audit log records the transmission with sender, recipient, included fields, and masking status + And integration errors (incomplete/rejected transmission) are logged and handled + + Examples: + | account_id | agency_api | balance_due | cardholder_name | card_number | last_4 | + | 12345 | /api/agency/hand | $800.00 | Alice Smith | 4012888888881881 | 1881 | + | 67890 | /api/agency/hand | $1200.00 | Bob Johnson | 5555555555554444 | 4444 | + | 24680 | /api/agency/hand | $1500.00 | Carol Lee | 4111111111111111 | 1111 | + + @api + Scenario Outline: Collection Agency Escalation at Policy Day Threshold with Error Handling + Given account "" is overdue for days and agency escalation boundary is + When system attempts to escalate to collection agency via API + Then escalation occurs only if overdue days meet threshold and API transmission includes only last 4 digits "" of card "" + And audit log reflects transmission, masking, and response (success/error) + And API masking errors or missing data trigger retry or block per policy + + Examples: + | account_id | overdue_days | boundary_days | card_number | last_4 | api_status | + | 12345 | 44 | 45 | 4012888888881881 | 1881 | not_triggered | + | 12345 | 45 | 45 | 4012888888881881 | 1881 | triggered | + | 67890 | 46 | 45 | 5555555555554444 | 4444 | triggered | + + # End-to-End Workflow & Masking + @e2e + Scenario: Full Credit Card Collection Lifecycle from Reminder to Legal Action + Given a cardholder account "" with valid card, due date, and escalation thresholds set + When system advances through lifecycle stages: due reminder, overdue, collection, payment plan proposal, agency handoff, legal escalation + Then at each stage, notifications, documents, and API transmissions include ONLY last 4 digits "" of card "" + And all state transitions are tracked and logged in audit trail + And no full card data is exposed in any notification, document, or log + And regulatory compliance is validated at every transition + + @e2e + Scenario Outline: Regulatory Audit Trail Verification across All Collection Lifecycle Events + Given cardholder account "" undergoes reminder, overdue, collection, payment plan, agency, legal, and error event stages + When each notification, transition, and escalation event occurs + Then audit logs capture masked card digits "", event type, recipient, role, timestamp, and regulatory compliance fields + And logs are complete, ordered, and accurate across all lifecycle events + And no exposure of full card information occurs + + Examples: + | account_id | card_number | last_4 | + | 12345 | 4012888888881881 | 1881 | + | 67890 | 5555555555554444 | 4444 | + + @e2e + Scenario: Audit and Masking Validation during External Document Generation for Collection Agency and Legal Partners + Given account in collection/agency/legal state and partner endpoints available + When system generates and transmits external documents with necessary data (agency/legal forms) + Then documents include ONLY last 4 digits "" of card + And secure transmission, receipt, and audit logging are completed + And any document generation with full card number is blocked and logged as error + + @e2e + Scenario: Cross-Account Data Integrity and State Transition + Given multiple credit card accounts "" and "" with separate overdue statuses + When workflows are triggered for each account (reminder, overdue, collection, agency, legal, reversal) + Then messages and logs reference ONLY correct account and last 4 digits + And no cross-account data appears in any communication or audit record + And state transitions are account-specific and comply with regulatory mandates + + @e2e + Scenario: Lifecycle Interruption and Recovery After System Outage with Masking Assurance + Given accounts in active collection lifecycle states and system outage occurs + When system recovers and resumes pending workflow steps + Then all resumed notifications and documents contain only last 4 digits + And audit log records outage period, paused actions, recovery events, and correct masking compliance + And no duplicate, out-of-order, or unmasked notifications after recovery + + # Negative Path & Error Handling API Tests + @negative + Scenario Outline: PII Masking Failure and Notification Transmission Exception Handling + Given simulated notification generation with full card number "" in payload or undeliverable contact "" + When system scans and attempts transmission + Then notification containing full card number is blocked and logged in audit + And administrator is alerted of masking error via error report + And notification transmission failures due to undeliverable contact are retried up to "" attempts, with audit logging and escalation + And NO unauthorized data transmission occurs + + Examples: + | card_number | contact | retry_limit | + | 4012888888881881 | bad.email | 3 | + | 5555555555554444 | +123456789 | 3 | + + @negative + Scenario Outline: Unauthorized Access Attempt and Cross-Account Data Leakage Prevention + Given user "" attempts to view/send collection notification or audit logs for "" as unauthorized + When system checks privilege matrix and access attempt + Then action is blocked and audit log records denied access with responsible user, role, and event + And NO cardholder/account/masked card data is leaked in notification or log + And cross-account reference attempts are detected and prevented + + Examples: + | role | target_account | expected_log | + | staff | 12345 | access_denied | + | external | 67890 | access_denied | + + @negative + Scenario Outline: Payment Plan Enrollment Failure and Error Notification + Given cardholder "" attempts payment plan enrollment with "" + When system detects error or invalid terms + Then masked error notification is sent (only last 4 digits "") + And audit log records failure event and rejected enrollment + And workflow reverts to previous state without exposing sensitive card info + + Examples: + | cardholder_name | failure_type | card_number | last_4 | + | Alice Smith | technical_error | 4012888888881881 | 1881 | + | Bob Johnson | invalid_installment | 5555555555554444 | 4444 | + + @negative + Scenario: Payment Plan Terms Violation Without Legal Escalation + Given account on payment plan with minor violation (late/partial payment below escalation threshold) + When system detects breach and triggers collection workflow + Then collection notifications include only last 4 digits + And no premature agency/legal escalation occurs + And audit log covers all workflow events and masking compliance + + @negative + Scenario Outline: Partial Payment Plan Acceptance and Workflow Handling Variations + Given payment plan proposal has been sent to cardholder "" with masked card info "" + When cardholder "" the plan or breaches terms + Then system modifies plan, escalates, or triggers breach process as per business rules + And all communications and audit logs include only last 4 digits + And workflow state transitions and regulatory compliance are validated + + Examples: + | cardholder_name | response_type | card_number | last_4 | + | Alice Smith | partial_accept| 4012888888881881 | 1881 | + | Bob Johnson | refuse | 5555555555554444 | 4444 | + | Carol Lee | breach | 4111111111111111 | 1111 | + + # Real-Time Dynamic Masking and Notification Adjustment API Tests + @api + Scenario Outline: Collection Notification with Dynamic Overdue Amount Adjustment + Given account "" in collection state with current overdue balance "" and masked card "" + When cardholder makes partial payment "" + Then system updates overdue balance and generates new notification with only last 4 digits + And audit log records all balance changes and masking compliance + And attempted notifications with stale/incorrect balance are blocked/logged + + Examples: + | account_id | overdue_amount | payment_amount | card_number | last_4 | + | 12345 | $500.00 | $100.00 | 4012888888881881 | 1881 | + | 67890 | $1000.00 | $250.00 | 5555555555554444 | 4444 | + + # Masked Legal Action API Tests + @api + Scenario Outline: Legal Action Documentation Generation and Transmission with Card Masking Enforcement + Given account "" in default and legal escalation workflow enabled + When system generates legal documents (summons, complaints) for "" + Then documents contain ONLY last 4 digits "" of card + And audit logs capture generation, transmission, recipients, and masking compliance + And regulatory compliance of legal documentation is validated + + Examples: + | account_id | recipient_type | card_number | last_4 | + | 12345 | cardholder | 4012888888881881 | 1881 | + | 12345 | legal_staff | 4012888888881881 | 1881 | + | 67890 | cardholder | 5555555555554444 | 4444 | + | 67890 | agency | 5555555555554444 | 4444 | + + # Payment Plan Proposal Boundary & Compliance API + @api + Scenario Outline: Payment Plan Proposal Timing and Compliance with Masking Enforcement + Given credit card account "" is overdue for "" days and collection notification has been sent + When payment plan eligibility window ( to overdue) is checked + Then proposal is sent ONLY if overdue days are within window, including only last 4 digits "" and regulatory terms + And proposal and audit log are compliant with masking and regulatory requirements + + Examples: + | account_id | overdue_days | min_days | max_days | card_number | last_4 | + | 12345 | 14 | 15 | 30 | 4012888888881881 | 1881 | + | 12345 | 15 | 15 | 30 | 4012888888881881 | 1881 | + | 67890 | 31 | 15 | 30 | 5555555555554444 | 4444 | + + # Multi-Channel Notification & Masking API Tests + @api @multi-channel + Scenario Outline: Multi-Channel Notification Content Verification and Role-Specific Masking + Given notification template is ready for "" and recipient role "" at workflow stage "" + When notification is triggered for cardholder "" with last 4 digits "" + Then delivered message contains only last 4 digits and is formatted according to channel and role + And audit log records channel, masking, recipient, and event details + And notifications with improper masking are blocked/logged + + Examples: + | channel | role | stage | cardholder_name | card_number | last_4 | + | email | cardholder | reminder | Alice Smith | 4012888888881881 | 1881 | + | sms | cardholder | overdue | Bob Johnson | 5555555555554444 | 4444 | + | in-app | cardholder | collection | Carol Lee | 4111111111111111 | 1111 | + | document | agency | handoff | Bob Johnson | 5555555555554444 | 4444 | + | document | legal_staff | legal | Alice Smith | 4012888888881881 | 1881 | + + # Notification Timing, Duplicate Prevention & Dynamic Due Date API + @api + Scenario Outline: Payment Due Reminder Timing & Duplicate Suppression – Masking Compliance + Given account "" with due date "" and reminder window "" to "" days before due + When reminder workflow is triggered at "" days before due date + Then notification is sent only if within window and includes only last 4 digits "" + And duplicate/out-of-window reminders are blocked and logged for suppression or invalid attempt + + Examples: + | account_id | due_date | window_min | window_max | days_before_due | card_number | last_4 | duplicate_attempt | + | 12345 | 2024-07-15 | 5 | 7 | 7 | 4012888888881881 | 1881 | No | + | 12345 | 2024-07-15 | 5 | 7 | 5 | 4012888888881881 | 1881 | No | + | 12345 | 2024-07-15 | 5 | 7 | 4 | 4012888888881881 | 1881 | No | + | 12345 | 2024-07-15 | 5 | 7 | 6 | 4012888888881881 | 1881 | Yes | + + @api + Scenario Outline: Dynamic Due Date Adjustment and Notification Window Compliance + Given account "" with original due date "" and reminder already sent + When due date is changed to "" (extend/shorten) + Then system recalculates reminder window and sends only in-window notifications (masked last 4 digits "") + And obsolete or duplicate reminders are suppressed and recorded in audit log + + Examples: + | account_id | original_due_date | new_due_date | card_number | last_4 | + | 12345 | 2024-07-15 | 2024-07-18 | 4012888888881881 | 1881 | + | 67890 | 2024-07-22 | 2024-07-19 | 5555555555554444 | 4444 | + + # Notification Preferences API Tests + @api + Scenario Outline: Multi-Channel Opt-In/Opt-Out Management for Collection Communications + Given cardholder "" accesses preferences and selects opt-in status "" for channel "" + When collection communication events (reminder, overdue, agency, legal) are triggered + Then cardholder receives notifications only via opted-in channels with only last 4 digits + And suppressed channels are honored immediately and audit log records preference changes + + Examples: + | cardholder_name | channel | opt_status | card_number | last_4 | + | Alice Smith | email | enabled | 4012888888881881 | 1881 | + | Bob Johnson | sms | disabled | 5555555555554444 | 4444 | + | Carol Lee | in-app | enabled | 4111111111111111 | 1111 | + + # Real-Time Retry and Failure Recovery API Tests + @api + Scenario Outline: Real-Time Notification Retry and Failure Recovery Mechanism Verification + Given account "" at workflow stage "" and contact "" with retry policy "" + When notification fails (network/channel/recipient) + Then system retries up to policy limit and each attempt includes only last 4 digits "" + And persistent failure escalates to administrator with masked error log + And audit log tracks all retries, masking, escalation, and recipient role + + Examples: + | account_id | stage | contact | retry_limit | card_number | last_4 | + | 12345 | overdue | bad.email | 3 | 4012888888881881 | 1881 | + | 67890 | reminder | +123456789 | 3 | 5555555555554444 | 4444 | + + # Escalation/De-Escalation State Transition API Tests + @api + Scenario Outline: Escalation and De-Escalation State Transition with Masking Enforcement + Given account "" is in "" and payment or plan is accepted + When system detects resolution and initiates state transition back to "active" + Then state change notifications to cardholder, agency, legal include only last 4 digits "" + And audit log records all escalation/de-escalation actions and masking compliance + And any attempted escalation/de-escalation with full card number is blocked/logged + + Examples: + | account_id | escalated_state | card_number | last_4 | + | 12345 | legal | 4012888888881881 | 1881 | + | 67890 | agency | 5555555555554444 | 4444 | + + # UI & Portal Tests (Functional + Accessibility) + @ui @portal + Scenario Outline: Cardholder Accepts Custom Payment Plan via Self-Service Portal + Given I am logged into the self-service portal as "" + When I review and accept payment plan proposal with masked card "" and adjust installment "" "" within policy + And I confirm and submit acceptance + Then confirmation and payment schedule are generated and displayed (with only last 4 digits) + And documents/messages are sent by selected channels, masked accordingly + And audit log records all portal actions + + Examples: + | cardholder_name | card_number | last_4 | installment_amount | installment_date | + | Alice Smith | 4012888888881881 | 1881 | $150.00 | 2024-08-01 | + | Bob Johnson | 5555555555554444 | 4444 | $200.00 | 2024-08-10 | + + @ui + Scenario: User Requests Detailed Breakdown of Collection Fees and Charges via Portal + Given I am the cardholder receiving collection notification (masked last 4 digits only) + When I request itemized breakdown of fees through portal/support + Then breakdown is displayed/sent including only last 4 digits for card reference + And unauthorized/unauthenticated users are denied access and audit log records request events + + @ui + Scenario Outline: Accessibility and Usability Verification of Collection Notifications and Portal Flows + Given notification templates and portal workflows are enabled + When visually impaired users access messages/docs with "" + And perform workflow actions using "" (screen reader, keyboard) + Then all content, masking, color contrast, structured markup, and navigation comply with WCAG 2.1 AA + And masked card info reveals only last 4 digits + And users can take independent action + And no accessibility loophole exposes sensitive card info + + Examples: + | assistive_technology | input_method | + | screen_reader | keyboard | + | color-contrast tools | keyboard | + | tab navigation | keyboard | + + # Non-Functional Bulk Processing, Performance + @performance + Scenario: Peak Load Performance Test for Bulk Collection Notification Dispatch + Given 50,000+ accounts in collection pipeline with varying lifecycle states + When bulk notification batch (reminder, overdue, collection, payment plan, agency handoff) is triggered + Then 95% of notifications are delivered within 15 min + And all communications/templates contain only masked last 4 digits of card + And system resource utilization remains within thresholds + And no lost, duplicated, or delayed notifications beyond tolerances + + # End-to-End Branching, Masking, Compliance + @api + Scenario: Formal Collection Notification and Payment Plan Proposal with Masked Card Number & Branch Coverage + Given account "" is delinquent and overdue alerts sent but not responded + When system triggers collection notification and checks payment plan eligibility + Then all communications include only last 4 digits + And audit log records collection, proposal, and response events + And workflow branches per cardholder acceptance, refusal, or no response + And regulatory compliance is validated + + @api + Scenario: User-Initiated Escalation Request and Immediate Agency/Legal Notification + Given cardholder authenticates and initiates escalation (dispute, debt restructure, legal) + When system prepares masked communication/document and transmits to agency/legal + Then notifications/documents include only last 4 digits, audit log records actions, and responses are properly masked + diff --git a/functional_tests/ZBIO-5213/ZBIO-5213.json b/functional_tests/ZBIO-5213/ZBIO-5213.json new file mode 100644 index 0000000..30064a4 --- /dev/null +++ b/functional_tests/ZBIO-5213/ZBIO-5213.json @@ -0,0 +1,395 @@ +[ + { + "type": "functional", + "title": "Automated Credit Card Due Reminder with Masked Card Number", + "description": "Validates automated due reminder notification sent to cardholder, enforcing last 4 digits only rule for card number.", + "testId": "TC-001", + "testDescription": "As a cardholder with an upcoming credit card payment due, I should receive an automated notification reminding me of the payment due date. The notification must include only the last 4 digits of my credit card number. No full or partial card numbers (other than last four) must appear in any communication. The system must log notification events for audit and regulatory compliance.", + "prerequisites": "Cardholder account exists and is active, with a credit card due date scheduled within the notification window. No previous due reminders sent within this cycle. Customer contact details (email, SMS, in-app) are valid.", + "stepsToPerform": "1. Set credit card account with next payment due in 5 days. 2. Trigger automated due reminder notification job. 3. System retrieves cardholder contact details. 4. Generate notification message, including cardholder name and last 4 digits of credit card. 5. Verify system masks the card number except for last 4 digits in message payload. 6. Send notification via chosen channel (email, SMS, app). 7. Log the notification event in system audit log. 8. Confirm receipt of notification by cardholder. 9. Validate notification content for structure, due amount, due date, and masking. 10. Check audit log for correct event record, user, and cardholder role.", + "expectedResult": "Due reminder notification is delivered to cardholder with only the last 4 digits of credit card number visible; full card number is never exposed. Message contains correct due date, due amount, structured content, and cardholder name. Audit log records notification, cardholder role, and masking compliant payload.", + "qualityAttribute": "security, masking, compliance, auditability, correctness", + "rolesTested": "cardholder, system", + "dataPoints": "account number, cardholder name, due date, due amount, last 4 digits of card", + "boundaryChecks": "due window is 1 to 7 days prior; verify reminder triggers at earliest and latest window" + }, + { + "type": "boundary", + "title": "Overdue Balance Alert at State Transition with Payment and Partial Payment Variations", + "description": "Tests overdue alert process, boundary value triggers, notification eligibility after missed payment including branch logic for payment, partial payment, and no payment cases.", + "testId": "TC-002", + "testDescription": "When a cardholder misses the payment due date, the system transitions the account to overdue state and sends a balance alert. Alert must show only last 4 digits of card. System must handle variations: no payment, partial payment, and late but full payment. Audit logs and compliance validation are required.", + "prerequisites": "Credit card account has payment due date today. No payment received by due date. System overdue processing job scheduled. Partial payment and late payment data setups.", + "stepsToPerform": "1. Set credit card with payment due date today. 2. Allow due date to pass with no payment. 3. Trigger overdue processing job. 4. System checks payment status – unpaid, partial, fully paid late. 5. Generate overdue alert with only last 4 digits of card number included. 6. Validate alert for correct overdue amount and structure. 7. Send alert to cardholder's contact method. 8. Record alert event and state change in audit log. 9. Repeat process for partial payment (cover partial, overdue remainder in alert). 10. For late payment, ensure alert is not sent and state resets.", + "expectedResult": "Overdue alert is sent to cardholder only when payment is unmade or partial; alert message masks card number except last four digits. Overdue amount and consequences are correct. Audit log records event, and system handles payment variations per business rules.", + "qualityAttribute": "state transition correctness, masking enforcement, regulatory audit, eligibility check", + "rolesTested": "cardholder, system", + "decisionTableCoverage": "payment status: unpaid, partial, late paid", + "boundaryChecks": "alert only triggers at end of due date; verify for 1-day late, exact due, and multiple-day late cases" + }, + { + "type": "functional", + "title": "Formal Collection Notification and Payment Plan Proposal with Masked Card Number", + "description": "Checks formal collection notification escalation, followed by payment plan proposal; verifies masking, regulatory data, and workflow branching.", + "testId": "TC-003", + "testDescription": "For accounts in delinquent state after multiple overdue notices, a formal collection notification is sent. System follows with a payment plan proposal if cardholder qualifies. All messages include only last 4 digits for card identification, no additional card data. Regulatory, audit, and branching variations must be validated.", + "prerequisites": "Credit card account is delinquent (overdue ≥ X days). Cardholder has received overdue alerts and not responded. System criteria for payment plan proposal eligibility set.", + "stepsToPerform": "1. Set account as delinquent (e.g., overdue for 30 days). 2. Trigger collection notification workflow. 3. Generate collection notification message with masked card number (last 4 digits only). 4. Send collection notice to cardholder. 5. Log collection event in compliance audit. 6. Check qualification for payment plan proposal. 7. Create payment plan message with only last 4 digits visible. 8. Send payment plan proposal to cardholder. 9. Cardholder accepts, rejects, or does not respond to proposal. 10. Log acceptance or refusal, and update account workflow status.", + "expectedResult": "Collection notification and subsequent payment plan proposal messages include correct last 4 digits, no full card number. Audit logs are complete for messages and responses. Workflow state transitions correctly upon cardholder acceptance or refusal.", + "qualityAttribute": "masking, branching logic, audit, workflow coverage, compliance", + "rolesTested": "cardholder, system", + "workflowCoverage": "collection, payment plan, response variation", + "dataPoints": "delinquent amount, payment plan terms, cardholder response", + "regulatoryCheck": "payment plan must meet regulatory terms if offered" + }, + { + "type": "end-to-end", + "title": "Full Credit Card Collection Lifecycle from Reminder to Legal Action", + "description": "Validates end-to-end lifecycle: due reminder, overdue, collection, payment plan, agency hand-off, legal escalation. Mandatory masking and auditing at all steps.", + "testId": "TC-004", + "testDescription": "Simulates the entire journey of a credit card account from upcoming payment reminder through overdue state, formal collection, payment plan proposal, agency involvement, and legal action. Ensures the last 4 digits masking rule is enforced at every stage, audit logs are created, and state transitions are tracked.", + "prerequisites": "Create cardholder account with valid card; schedule payment due date in near future; set up escalation thresholds and contact channels for all parties (cardholder, agency, legal).", + "stepsToPerform": "1. Set up account with payment due in 5 days. 2. Trigger due reminder notification workflow and validate masked card number. 3. Allow due date to pass with no payment; trigger overdue alert, verify masking and audit log. 4. System escalates to formal collection notification after further delay; check content and masking. 5. If eligible, offer payment plan proposal; log response and update state. 6. If payment plan not accepted or breached, escalate to collection agency; send only last 4 digits to agency, verify secure transmission. 7. If balance unresolved after agency effort, initiate legal action; generate legal documentation with masked card number. 8. Send copy of legal documentation to cardholder and agency; check audit logs and compliance at all transition points. 9. At each stage, validate no full card number exposure in all records, notifications, and integrations. 10. Review audit logs for complete state transition veracity.", + "expectedResult": "Account undergoes full lifecycle; all communications and documents feature only last 4 digits, with correct state transitions, regulatory compliance, audit logs, and secure agency/legal integration. No full card data exposed at any stage.", + "qualityAttribute": "end-to-end workflow coverage, masking, compliance, integration, auditing, role handling", + "rolesTested": "cardholder, system, collection agency, legal staff", + "boundaryChecks": "trigger points for escalation: overdue day counts, payment plan acceptance/rejection", + "integrationPoints": "agency hand-off, legal system hand-off", + "regression": "existing workflows for reminders and collections" + }, + { + "type": "negative", + "title": "PII Masking Failure and Notification Transmission Exception Handling", + "description": "Tests system response to accidental inclusion of full or partial card number, and failed notification transmission; verifies proper error handling and audit log.", + "testId": "TC-005", + "testDescription": "When the notification generation logic erroneously includes full credit card number, or notification fails due to undeliverable contact channel, the system must detect, block, log, and escalate the error. No communication with PII violation must be transmitted.", + "prerequisites": "Simulated bug in notification template logic to include full card number; invalid or unreachable cardholder contact method; audit logging enabled.", + "stepsToPerform": "1. Insert bug or data corruption to generate notification with full card number. 2. Attempt to trigger due reminder notification workflow. 3. System scans message payload for PII compliance before transmission. 4. Detect presence of full or partial card data (other than last four digits). 5. Block notification transmission; log error in compliance and audit log. 6. Notify administrator of PII masking failure via error report. 7. Attempt notification transmission to invalid contact method (e.g., unreachable email/SMS). 8. Notification transmission fails; system retries up to policy limit. 9. On repeated failure, flag event for manual review and escalate according to workflow. 10. Validate audit logs for presence of both error events and absence of unauthorized data transmission.", + "expectedResult": "Notification containing full card number is blocked and never transmitted. Notification transmission failures due to undeliverable contact are retried and logged, with escalation after repeated failures. Detailed audit logs are available for all exception events.", + "qualityAttribute": "security, masking enforcement, error handling, audit, escalation", + "rolesTested": "system, administrator", + "dataPoints": "full card number, transmission error code, audit record", + "boundaryChecks": "masking rule violation, notification retry count limit", + "regression": "notification and error handling routines" + }, + { + "type": "boundary", + "title": "Collection Notification Trigger at Delinquency Threshold with Fee Calculation", + "description": "Validates correct triggering of collection notification based on overdue days, verifies boundary scenarios for fee calculation, and ensures masking compliance.", + "testId": "TC-006", + "testDescription": "As a cardholder whose account has crossed the defined delinquency threshold (e.g. 30 days overdue), I should receive a formal collection notification. The notification must include the last 4 digits of the card, computed overdue amount, and associated fees (including late charges), but must NEVER expose full card number or additional PII. Boundary value analysis covers edge cases at threshold days and fee calculation accuracy.", + "prerequisites": "Credit card account is overdue; system has configured collection notification trigger at specific day threshold (e.g., 30 days); overdue balance and late fee calculation logic set up.", + "stepsToPerform": "1. Set credit card with overdue balance for 29 days. 2. Verify no collection notification is triggered at 29 days. 3. Advance overdue status to 30 days. 4. Trigger collection notification process. 5. Generate notification with overdue amount, late fee, and last 4 digits of card only. 6. Verify notification content for accuracy and masking. 7. Send notification to cardholder. 8. Confirm event is logged in audit trail. 9. Check system for fee calculation correctness at threshold. 10. Validate that no full card number appears in message or logs.", + "expectedResult": "Collection notification is sent only at threshold (30 days overdue). Notification includes accurate overdue amount, calculated late fee, and masks card number except last 4 digits. Audit log records event and fee computation. No full card number exposure.", + "qualityAttribute": "boundary handling, masking, fee calculation, audit compliance", + "rolesTested": "cardholder, system", + "dataPoints": "overdue amount, late fee, delinquency days, last 4 digits", + "boundaryChecks": "29 days (no notification), 30 days (trigger collection), fee calculation cutoff" + }, + { + "type": "functional", + "title": "Collection Agency Data Hand-Off and Integration with Masked Card Number", + "description": "Validates secure and compliant hand-off of account information to third-party collection agency, enforcing PII masking, audit, and integration workflows.", + "testId": "TC-007", + "testDescription": "When collection agency involvement is triggered, the system must securely transmit only the necessary account information (amount owed, last 4 digits of the card, cardholder name) to authorized third-party. System must prevent exposure of full card number or other PII, ensure agency can process account, and create auditable records of the transfer.", + "prerequisites": "Delinquent account pending collection agency escalation; agency credentials validated; integration endpoints configured.", + "stepsToPerform": "1. Set cardholder account as eligible for agency escalation. 2. System prepares data package for agency, including balance due, cardholder name, and last 4 digits of card. 3. Apply masking logic before data export. 4. Transfer data securely over configured channel (API/message queue). 5. Agency system receives and acknowledges data. 6. Validate agency record for correct masking and data structure. 7. Review audit log for transmission record, included fields, sender & recipient. 8. Initiate agency collection workflow and confirm state transition in customer account. 9. Confirm no full card number is accessible by agency. 10. Validate integration error handling for incomplete or rejected agency transmissions.", + "expectedResult": "Data transferred to collection agency includes only last 4 digits of card, correct balance, and necessary PII. Audit log records transfer event with security compliance. Agency cannot access full card number. Any integration failures are logged and handled.", + "qualityAttribute": "integration, masking, compliance, auditability, error handling", + "rolesTested": "collection agency, system", + "dataPoints": "amount owed, cardholder name, last 4 digits of card, agency recipient", + "integrationPoints": "agency API, message queue, error reporting" + }, + { + "type": "negative", + "title": "Unauthorized Access Attempt and Cross-Account Data Leakage Prevention", + "description": "Ensures robust access controls and verifies the system does not allow unauthorized data or cross-account information leakage in notifications or logs.", + "testId": "TC-008", + "testDescription": "If an unauthorized user (e.g., unrelated bank staff or external party) attempts to view or send credit card communication, system must block the action, prevent all card or account data exposure, and log event. Also covers attempts to access another customer’s masked card info, enforcing boundary scenarios and robust role-based authorization.", + "prerequisites": "Credit card account exists for multiple customers; access privilege matrix established; system monitoring/logging enabled.", + "stepsToPerform": "1. Log in as unauthorized user (e.g., bank staff with no collection privileges). 2. Attempt to retrieve notification history or content for a credit card account not belonging to authorized role. 3. Try to generate or send a collection notification with improper access. 4. Attempt to view internal audit or transmission logs for other customer accounts. 5. System checks privilege against role and account owner. 6. System blocks all unauthorized actions, returns access denied messages. 7. Audit log records attempted access, role, and denied event. 8. Verify no cardholder or masked card data is included in unauthorized log entries. 9. Attempt to cross-reference notifications between accounts. 10. Ensure no data leakage occurs in any internal/external communication.", + "expectedResult": "System prevents all unauthorized access attempts; no cardholder, account, or masked card data is leaked. Audit log records the denied actions and responsible user. No cross-account notification or log contamination.", + "qualityAttribute": "security, authorization, data integrity, audit, compliance", + "rolesTested": "system, unauthorized staff, administrator", + "dataPoints": "access denied logs, attempted user roles, account info", + "boundaryChecks": "privilege boundary (authorized vs. unauthorized), cross-account reference" + }, + { + "type": "functional", + "title": "Legal Action Documentation Generation and Transmission with Card Masking Enforcement", + "description": "Validates legal documentation creation and secure delivery, enforcing masking for last 4 digits and comprehensive audit trail requirements.", + "testId": "TC-009", + "testDescription": "Accounts escalated to legal action must trigger generation of legal documentation (summons, claim statements) containing only the last 4 digits of card and necessary PII. System must transmit documentation securely to cardholder and legal staff, maintain audit logs of generation/transmission, and guarantee that no full card data appears in any legal artifact or external communication.", + "prerequisites": "Account in default; legal escalation workflow enabled; document templates prepared; cardholder/legal staff contact details configured.", + "stepsToPerform": "1. Flag account for legal action escalation. 2. Create legal documents (summons, complaint) with masked card information (last 4 digits only). 3. Validate template content for correct PII and card masking. 4. Securely transmit documents to cardholder and legal entity. 5. Audit document generation event, transmission, and recipients. 6. Review recipient’s received documents for masking compliance. 7. Confirm account state is updated to legal action status. 8. Verify system does not expose full card number in any generated document, log, or integration. 9. Validate regulatory compliance of legal documentation. 10. Test reversal/cancellation path for legal action and impact on audit log.", + "expectedResult": "Legal documents generated and transmitted contain only masked card information (last 4 digits). Audit trail is complete for document events. Legal staff and cardholder receive compliant documentation. No full card data is exposed at any stage.", + "qualityAttribute": "masking, compliance, audit, secure communication, regulatory", + "rolesTested": "legal staff, cardholder, system", + "dataPoints": "legal action documents, cardholder info, last 4 digits, audit log", + "integrationPoints": "legal system, secure document delivery" + }, + { + "type": "end-to-end", + "title": "Regulatory Audit Trail Verification across All Collection Lifecycle States", + "description": "Exhaustively checks audit and compliance logging for all notifications, transitions, escalations, and failed events from reminder through legal action.", + "testId": "TC-010", + "testDescription": "For any account passing through multiple collection lifecycle stages, every event (notification generation, overdue alert, collection notice, payment plan proposal, agency hand-off, legal escalation, transmission errors) must be logged with accurate, time-stamped records. Audit logs must reflect masked card number only, event type, recipient, system role, and compliance with regulatory mandates. Includes validation of log completeness, integrity, and role tracking.", + "prerequisites": "Cardholder account setup; lifecycle timeline simulated (reminder, overdue, collection, payment plan, agency, legal); audit and compliance logging enabled.", + "stepsToPerform": "1. Trigger payment reminder notification, capture audit log for event. 2. Allow overdue alert, review log entry for masking and data points. 3. Escalate to collection notification; extract audit records for recipient and masking. 4. Offer and respond to payment plan proposal; validate multiple log entries for proposal and cardholder action. 5. Escalate account to agency, confirm agency hand-off is logged with masking compliance. 6. Initiate legal action, generate and transmit documents, check logs for legal events. 7. Simulate failed notification or transmission, confirm audit logs record error with no card data exposure. 8. Review logs for role, state, and recipient at all workflow stages. 9. Validate regulatory fields and log structure meets compliance. 10. Test audit log retrieval and verify completeness, order, and accuracy across lifecycle.", + "expectedResult": "Full audit trail is available for every lifecycle stage—reminder, overdue, collection, payment plan, agency, legal—with no exposure of full card information. Logs reflect all events, recipients, roles, masking, errors, and compliance fields as mandated.", + "qualityAttribute": "auditability, completeness, masking, regulatory compliance, role handling", + "rolesTested": "system, cardholder, administrator, agency, legal staff", + "dataPoints": "audit log fields (event, masked card digits, timestamp, role, recipient, error code)", + "stateTransitions": "reminder, overdue, collection, payment plan, agency, legal, error" + }, + { + "type": "boundary", + "title": "Payment Plan Proposal Timing and Compliance with Masking Enforcement", + "description": "Validates eligibility boundary and timing for payment plan proposal after collection notification, ensuring masking, regulatory terms, and audit log completeness.", + "testId": "TC-011", + "testDescription": "When a cardholder becomes eligible for a payment plan after receiving a collection notification, the system must offer the proposal only within allowed overdue days. Proposal must include last 4 digits of card, regulatory schedule and terms, and regulatory compliant masking. Checks boundaries for minimum and maximum overdue days for eligibility and proper audit logging.", + "prerequisites": "Account overdue for multiple days (e.g., overdue for 15, 16, 30 days); payment plan eligibility criteria configured; collection notification already sent; audit logging enabled.", + "stepsToPerform": "1. Set credit card account to 14 days overdue (below payment plan threshold). 2. Trigger workflow and validate that no payment plan proposal is sent. 3. Advance account status to 15 days overdue (boundary for payment plan eligibility). 4. Trigger payment plan proposal workflow. 5. Generate proposal with masked card number (last 4 digits only). 6. Validate proposal content for terms and compliance with regulatory requirements. 7. Send proposal to cardholder and log event in audit records. 8. Confirm cardholder receives compliant proposal. 9. Attempt to trigger proposal outside allowed window (e.g., >30 days overdue) and validate expected behavior. 10. Review audit logs for all proposal events and masking compliance.", + "expectedResult": "Payment plan proposal is sent only to eligible accounts at correct boundary window. Proposal always includes only last 4 digits of card. Regulatory terms and audit logs are compliant. No proposal is sent outside eligibility boundaries. Masking verified in all records.", + "qualityAttribute": "boundary coverage, masking, eligibility correctness, regulatory terms, audit log", + "rolesTested": "cardholder, system", + "boundaryChecks": "payment plan eligibility (min/max overdue days), masking rule" + }, + { + "type": "negative", + "title": "Partial Payment Plan Acceptance and Workflow Handling", + "description": "Tests different outcomes of payment plan proposal: partial acceptance, refusal, or breach, ensuring workflow transitions and masking at each state.", + "testId": "TC-012", + "testDescription": "If the cardholder accepts only part of the payment plan terms, refuses, or defaults after accepting, system must adjust the workflow—either modify plan, escalate to collections or legal, and always confirm all communications and audit logs include only last 4 digits of card.", + "prerequisites": "Account in overdue state; payment plan proposal sent; cardholder response options available (accept partial, refuse, breach after accepting); audit logging enabled.", + "stepsToPerform": "1. Send payment plan proposal to cardholder with masked card info. 2. Cardholder accepts partial terms, e.g., only partial installment or reduced payment. 3. System reviews acceptance and modifies plan as per business rules. 4. Cardholder refuses plan; system escalates workflow to collections or agency. 5. Cardholder initially accepts plan but fails to pay as scheduled. 6. System triggers breach process and sends formal escalation notice (masked card digits only). 7. Log all responses and actions in audit trail. 8. Validate masking compliance in each communication and log. 9. Check workflow state transitions for each response scenario. 10. Verify regulatory compliance on escalation after breach.", + "expectedResult": "System properly handles all payment plan response scenarios. Masking is enforced in all messages and logs. Workflows transition correctly for partial acceptance, refusal, or breach. Audit logs are complete and compliant.", + "qualityAttribute": "negative/exception coverage, workflow branching, masking, audit, regulatory compliance", + "rolesTested": "cardholder, system", + "workflowCoverage": "payment plan partial acceptance, refusal, breach" + }, + { + "type": "functional", + "title": "Multi-Channel Notification Content Verification and Role-Specific Masking", + "description": "Confirms notification content structure and masking for email, SMS, in-app, and external documentation; enforces role-based message formatting.", + "testId": "TC-013", + "testDescription": "System must deliver notifications and documents via multiple channels (email, SMS, in-app, agency/legal hand-off) with correct structure and masking for last 4 digits only. Ensures message format and sensitive data exposure are adjusted by recipient role (cardholder, agency, legal staff) and channel.", + "prerequisites": "Credit card account with workflow states requiring communication (reminder, overdue, collection, agency, legal); templates for each channel and role configured; audit logging enabled.", + "stepsToPerform": "1. Trigger notification for upcoming payment due via email. 2. Trigger overdue alert via SMS. 3. Send collection notification through in-app messaging. 4. Transfer masked account data to agency as external document. 5. Generate legal documentation and deliver to legal staff. 6. Review all messages for masking (last 4 digits only) and recipient-specific formatting. 7. Validate message payload for correct structure, amount, dates, and consequences. 8. Confirm audit log records transmission channel, recipient role, event type, and masking status. 9. Test improper masking scenario for any channel and verify system blocks/discards message. 10. Validate regulatory compliance for each communication method and recipient.", + "expectedResult": "All communications contain only last 4 digits in appropriate format by channel and recipient role. Audit logs include channel, masking, recipient and event details. No full card number is exposed in any channel or document.", + "qualityAttribute": "multi-channel coverage, masking, message formatting, audit, compliance, role handling", + "rolesTested": "cardholder, agency, legal staff, system", + "channelsCovered": "email, SMS, in-app, external documents" + }, + { + "type": "end-to-end", + "title": "Cross-Account Data Integrity and State Transition Test", + "description": "Exhaustively validates no cross-account information appears in communications or logs and all lifecycle state transitions reflect card-specific data with masking.", + "testId": "TC-014", + "testDescription": "When multiple cardholder accounts undergo collection workflows simultaneously, system must enforce strict separation of data. All communications, notifications, logs, and documents must reference only appropriate card/account and include only last 4 digits. Lifecycle state transitions (reminder, overdue, collection, agency, legal) must update only the relevant account and not leak data between customers.", + "prerequisites": "Multiple credit card accounts set up with unique card numbers and overdue states; collection, agency, legal escalation enabled; audit logging and masking logic configured.", + "stepsToPerform": "1. Set up accounts A and B with separate overdue statuses. 2. Trigger payment reminder for account A; verify message and log reference only A. 3. Trigger overdue and collection notifications for account B; validate message/log references only B. 4. Initiate payment plan to A; escalate B to agency involvement. 5. Generate agency hand-off for B and legal documentation for A. 6. Confirm all messages and logs include only respective account and last 4 digits, no cross-referencing. 7. Attempt to generate notification with both A and B's card info—system must block or flag error. 8. Review audit logs for each lifecycle event and recipient. 9. Test reversal of state for A (e.g., payment made) and verify state transition reflects only A. 10. Validate regulatory compliance for all separation events.", + "expectedResult": "Strict account separation enforced; masked card info (last 4 digits) and communications/logs always reference only relevant account. No cross-account data appears in notifications, documents, or logs. State transitions and reversal events are account-specific.", + "qualityAttribute": "data integrity, masking, account separation, audit, state transition, compliance", + "rolesTested": "cardholder, system, agency, legal staff", + "stateTransitions": "reminder, overdue, collection, agency, legal, reversal" + }, + { + "type": "boundary", + "title": "Collection Agency Escalation Day Thresholds and API Integration Handling", + "description": "Validates escalation to collection agency at policy day boundary, secure API integration, and rejection error path with masking compliance.", + "testId": "TC-015", + "testDescription": "When overdue account crosses policy boundary (e.g., 45 days), system must escalate to collection agency using secure, masked API integration. Tests day threshold boundary, successful and failed API hand-off, and audit trace for masked digits only.", + "prerequisites": "Delinquent account overdue for several days; agency escalation policy boundary set (e.g., 44/45 days); API integration with collection agency configured; audit logging enabled.", + "stepsToPerform": "1. Set account to 44 days overdue (below boundary). 2. Attempt agency escalation—validate not triggered. 3. Advance to 45 days overdue (boundary day). 4. Trigger agency escalation workflow. 5. Prepare account data (balance, last 4 digits) for API transmission. 6. Send API call to agency; monitor transmission for masking compliance. 7. Agency returns success/error response; system logs transmission event and masked data. 8. Simulate agency API rejection due to masking error or missing data, system must block or retry. 9. Validate audit logs on successful hand-off and error retry path. 10. Confirm no full card number is exposed in any API payload, log, or agency record.", + "expectedResult": "Collection agency escalation occurs only at policy boundary. API transmission always includes only last 4 digits. Audit logs reflect transmission/reply events with masking compliance. System handles API rejection/error per business rules. No full card number exposure.", + "qualityAttribute": "integration, boundary trigger, masking, audit, error handling", + "rolesTested": "system, agency", + "boundaryChecks": "agency escalation day threshold, API masking errors" + }, + { + "type": "functional", + "title": "User Requests Detailed Breakdown of Collection Fees and Charges", + "description": "Assures a cardholder receives a clear, itemized breakdown of all fees, penalties, and charges applied to their overdue credit card balance in the collection notification, with strict card masking.", + "testId": "TC-016", + "testDescription": "As a cardholder who receives a formal collection notification, I want to request and review a transparent, itemized list of all additional charges so that I can understand how my overdue amount was calculated. The breakdown and any corresponding communication must only expose the last 4 digits of my card number.", + "prerequisites": "Cardholder account is in delinquent/collection state; collection notification with additional charges has been issued; user authentication is in place.", + "stepsToPerform": "1. Receive formal collection notification as a cardholder (last 4 digits only).\n2. Access the digital portal or contact support to request itemized fee breakdown.\n3. System retrieves and prepares a list outlining initial overdue amount, late fees, interest, penalties, and administrative charges with descriptions.\n4. System generates the response notification, including only the last 4 digits of the card for identification.\n5. Cardholder reviews breakdown in their chosen channel (portal, email, or secured message).\n6. Attempt to retrieve the breakdown with an unauthenticated or unauthorized user.", + "expectedResult": "Cardholder receives a fully itemized, clear breakdown of all charges with the last 4 digits of their card number. No full/partial card numbers are exposed. Unauthorized users are denied access and audit logs are updated with request events." + }, + { + "type": "functional", + "title": "Cardholder Accepts and Initiates Custom Payment Plan through Self-Service Portal", + "description": "Validates the end-to-end user flow for a cardholder accepting a payment plan proposal via a web/mobile portal, entering custom installment details, and initiating the plan with all communications strictly masking card details.", + "testId": "TC-017", + "testDescription": "As a cardholder unable to pay the full overdue amount, I want to accept a payment plan proposal and adjust installment dates or amounts (according to policy) so that I can manage my repayment schedule. All plan-related documents and communications must show only the last 4 digits of my card number.", + "prerequisites": "Account is delinquent and eligible for a payment plan; portal access is active; payment plan proposal has been sent; cardholder has sufficient authentication.", + "stepsToPerform": "1. Cardholder logs into the self-service portal.\n2. Reviews and accepts the payment plan proposal (with last 4 digits of card displayed only).\n3. Optionally adjusts allowed installment options (amount, schedule) within policy.\n4. Confirms acceptance; system generates confirmation, payment schedule, and T&Cs—all documents show only last 4 digits of card.\n5. Notification and schedule are sent via user-selected channel(s) with proper masking.\n6. System audit log records all actions, state changes, and communications.", + "expectedResult": "User can configure and accept the payment plan within permitted limits. All communications contain only the last 4 digits as card reference. System audit logs all events and no full card number is ever exposed." + }, + { + "type": "non-functional", + "title": "Accessibility and Usability Verification of All Collection Notifications", + "description": "Ensures all user-facing collection lifecycle notifications (reminders, overdue, agency, legal) are readable via screen readers, navigable by keyboard, accessible by visually impaired cardholders, and compliant with WCAG 2.1 AA.", + "testId": "TC-018", + "testDescription": "As a visually impaired cardholder, I want to independently read and interact with all notification content and make payment or contact support, regardless of channel. All communications and portal workflows must meet accessibility standards and maintain proper card masking.", + "prerequisites": "All notification templates (email, SMS, in-app, web portal, downloadable documents) are generated. Assistive technologies (screen readers, keyboard navigation, color-contrast tools, etc.) are available.", + "stepsToPerform": "1. Receive reminder, overdue, collection, agency, and legal notifications in all channels.\n2. Open each message or document with a screen reader—verify reading order and clarity.\n3. Attempt to complete workflow actions (accept payment plan, view breakdown, contact support) using keyboard navigation only.\n4. Verify color contrast ratios, alt text, link focus states, and structured markup for all notifications and portal flows.\n5. Review masking for all masked card info—ensure no accessibility workaround exposes full card number.\n6. Attempt payment or response flows as a user relying exclusively on assistive technology.", + "expectedResult": "All collection communication and portal journeys are accessible to users with disabilities per WCAG 2.1 AA. All card references show only the last 4 digits. No sensitive data is exposed or inaccessible due to UI issues. Cardholders can independently take necessary actions." + }, + { + "type": "non-functional", + "title": "Peak Load Performance Test for Bulk Collection Notification Dispatch", + "description": "Assesses system’s ability to generate, mask, and send thousands of collection notifications within SLAs during end-of-billing or quarter-peak batch processing.", + "testId": "TC-019", + "testDescription": "As an operations administrator, I want the system to efficiently process and deliver a very large batch of collection-related communications (reminders, overdue alerts, payment plan offers, agency hand-offs) during monthly/quarterly cycles—without SLA breach, notification errors, or masking lapses.", + "prerequisites": "High account volume (e.g., 50,000+) in collection pipeline with varying workflow states; batch notification process is enabled; system monitoring active.", + "stepsToPerform": "1. Prepare 50,000+ accounts, each with varying collection lifecycle states.\n2. Trigger bulk notification batch (reminder, overdue, collection, payment plan, agency hand-off) for all eligible accounts.\n3. Monitor response times for notification generation, masking, transmission, and error handling.\n4. Track SLA compliance for delivery windows (e.g., 95% within 15 min).\n5. Sample random notifications in each batch to verify only last 4 digits appear—no batch/parallel processing masking failures.\n6. Capture system resource utilization (CPU, memory, IO, queue backlog) and error logs during test.", + "expectedResult": "System completes bulk processing within agreed SLAs. All notifications and documents show only last 4 digits of each respective card—no masking failures. Resource utilization remains within operational thresholds. No notifications are lost, duplicated, or delayed beyond allowed tolerances." + }, + { + "type": "functional", + "title": "Multi-Channel Opt-In/Opt-Out Management for Collection Communications", + "description": "Tests a cardholder’s ability to manage preferences for receiving collection communications (e.g., via email, SMS, in-app, paper) and verifies proper handling, masking, and suppression as per user choice.", + "testId": "TC-020", + "testDescription": "As a cardholder, I want to opt in or out of specific communication channels for collection lifecycle messages, so that I control how and where sensitive notifications (with last 4 digits) are delivered.", + "prerequisites": "User preferences management system enabled; multiple notification channels configured; cardholder account enrolled and authenticated; masking logic applied to all templates.", + "stepsToPerform": "1. Cardholder accesses preferences portal and enables/disables channels for reminders, overdue alerts, and collection communications.\n2. User saves settings and system updates profile.\n3. Reach each collection milestone (reminder, overdue, agency, legal escalation).\n4. Monitor system delivering notifications only via enabled channels (all containing only last 4 digits for card ID).\n5. Attempt to send notification via an opted-out channel (ensure suppression and audit log recorded).\n6. System-resend or fallback to alternate channels if primary channel fails, obeying masking rules.", + "expectedResult": "Cardholder receives communications only via opted-in channels. All notifications display only last 4 digits of card. No sensitive notifications are sent via disabled channels. Changes to preferences are honored immediately and recorded in the audit log." + }, + { + "type": "boundary", + "title": "Payment Due Reminder Timing and Duplicate Notification Suppression", + "description": "Validates boundary values for due reminder notification timing and ensures system prevents duplicate reminders within the notification window; checks masking adherence.", + "testId": "TC-021", + "testDescription": "As a cardholder, I should receive a payment due reminder exactly once within each notification window (e.g., 5–7 days before due date), with no repeats. The system must enforce only the last 4 digits of my card number in all reminders. Duplicate notifications or out-of-window reminders are errors.", + "prerequisites": "Active cardholder account with upcoming payment due. Notification window parameters defined (e.g., min 5, max 7 days before due). No reminder previously sent for this cycle.", + "stepsToPerform": "1. Configure account with payment due in 7 days.\n2. Trigger reminder workflow—expect notification to cardholder.\n3. Verify reminder includes only last 4 digits of card.\n4. Attempt to trigger reminder again within window—system must suppress duplicate.\n5. Advance time to 4 days before due—attempt reminder, and validate no notification sent.\n6. Check audit logs for all reminder events and suppression records.\n7. Attempt reminder generation outside window (e.g., 8 days before)—validate no notification issued.\n8. Test hypothetical bug where reminder sent twice; verify detection and audit logging.", + "expectedResult": "Due reminder is sent only once per cycle within window. Message includes only last 4 digits of card. Duplicate or out-of-window reminders are blocked and logged. Audit trail records successful, suppressed, and invalid attempts.", + "qualityAttribute": "boundary handling, masking, duplicate prevention, audit, regulatory compliance", + "rolesTested": "cardholder, system", + "boundaryChecks": "reminder timing window, duplicate suppression", + "regression": "reminder generation workflow" + }, + { + "type": "negative", + "title": "Failed Payment Plan Enrollment and Notification Path Exception", + "description": "Verifies system behavior when payment plan enrollment fails (e.g., technical error, invalid terms), ensuring correct masking in all error notifications and proper workflow recovery.", + "testId": "TC-022", + "testDescription": "If a cardholder attempts to enroll in a payment plan but the process fails due to system error, invalid input, or regulatory check failure, the system must notify the user securely (with only last 4 digits), log the error, and recover workflow without exposing sensitive card data.", + "prerequisites": "Delinquent account with payment plan proposal issued; cardholder attempts enrollment via portal; error simulation or invalid input (e.g., over installment limits) injected.", + "stepsToPerform": "1. Cardholder submits payment plan acceptance with valid authentication.\n2. Inject technical error (e.g., database failure) or invalid installment schedule.\n3. System detects failure and blocks enrollment.\n4. Generate error notification to cardholder including only last 4 digits.\n5. Log failure event and rejected enrollment in audit records.\n6. Verify workflow reverts to previous state (collection pending).\n7. System does not escalate to agency or legal unless required.\n8. Attempt to re-enroll; verify proper masking and error handling.", + "expectedResult": "Payment plan enrollment failure results in masked error notification, logged audit event, and workflow state recovery. No sensitive card info is exposed. User can retry or escalate according to business rules.", + "qualityAttribute": "error handling, masking, workflow recovery, audit, compliance", + "rolesTested": "cardholder, system", + "dataPoints": "failed proposal, error notification, last 4 digits, audit log", + "workflowCoverage": "payment plan, error recovery" + }, + { + "type": "functional", + "title": "Collection Notification with Dynamic Overdue Amount Adjustment", + "description": "Ensures system responds to real-time changes in the overdue amount (e.g., cardholder makes partial payments during collection window), adjusts notification content and masking accordingly.", + "testId": "TC-023", + "testDescription": "As a cardholder in collection, I may make partial payments before full settlement. The system must update the overdue balance in real time and reflect the adjusted amount in subsequent collection notifications—always with last 4 digits only for card reference.", + "prerequisites": "Account is in collection state; partial payments possible; overdue balance fluctuates; audit logging enabled.", + "stepsToPerform": "1. Trigger collection notification with current overdue balance (last 4 digits only).\n2. Cardholder makes partial payment, system updates overdue balance.\n3. Generate new collection notification referencing updated amount and masked card digits.\n4. Send updated notification to cardholder.\n5. Log all balance change events and notification actions.\n6. Attempt to send notification with stale or incorrect balance—system must block or update.\n7. Review audit log for masking compliance and balance accuracy.\n8. Confirm no full card number appears at any stage.", + "expectedResult": "Collection notifications always reflect current overdue balance, adjusted for partial payments, and include only last 4 digits of card. Stale or incorrect balance triggers errors and audit logging. Masking compliance verified in all notifications.", + "qualityAttribute": "correctness, masking, dynamic data handling, audit, compliance", + "rolesTested": "cardholder, system", + "dataPoints": "collection balance, partial payment amount, last 4 digits", + "regression": "collection notification workflow" + }, + { + "type": "functional", + "title": "Escalation and De-Escalation State Transition with Masking Enforcement", + "description": "Validates bidirectional state transitions—account escalates to collection/agency/legal due to non-payment and returns to normal upon payment—with mandatory masking and audit checks.", + "testId": "TC-024", + "testDescription": "When a cardholder resolves delinquency (e.g., pays off overdue or accepts payment plan after escalation), the system must transition the account status back to active/good standing. All communications on state changes must include only last 4 digits of card. De-escalation sequence is audited and masking must never lapse.", + "prerequisites": "Account escalated to collection, agency, or legal; payment made or plan accepted; reversal/de-escalation logic configured; audit logging enabled.", + "stepsToPerform": "1. Account is in legal/agency/collection state (with masked card references in notices).\n2. Cardholder completes payment or accepts plan as per policy conditions.\n3. System detects payment and initiates state transition back to active.\n4. Generate state change notification to cardholder, agency, legal team (if applicable) with only last 4 digits.\n5. Update account status and close escalation workflow.\n6. Log all transition actions and notification deliveries in audit trail.\n7. Attempt to escalate/de-escalate with full or partial card number—system blocks and logs error.\n8. Verify masking in all notifications and audit entries for both escalation and de-escalation.", + "expectedResult": "Account can be escalated or returned to active status as required. All state change communications include only last 4 digits of card; audit logs are complete and masking compliance never fails.", + "qualityAttribute": "state transition, masking, audit, compliance, workflow reversal", + "rolesTested": "cardholder, system, agency, legal staff", + "stateTransitions": "collection, agency, legal, active, de-escalation" + }, + { + "type": "end-to-end", + "title": "Audit and Masking Validation during External Document Generation for Collection Agency and Legal Partners", + "description": "Assures all externally generated documents (PDFs, legal templates, agency forms) produced by the system for agency/legal hand-off strictly contain only the last 4 digits of card and fully capture audit events for compliance.", + "testId": "TC-025", + "testDescription": "Whenever collection agency or legal escalation requires production and hand-off of documents (external PDFs, forms, legal templates), the system must generate only properly masked documents, transmit securely, and audit every creation/transmission event. No unmasked card data can be present in any external artifact.", + "prerequisites": "Account is in collection/agency/legal state; external document templates in place; agency/legal system endpoints available; audit logging and masking logic configured.", + "stepsToPerform": "1. Trigger external document generation for agency or legal partners.\n2. Populate forms with necessary data—only last 4 digits for card reference.\n3. Validate all generated document content for masking and data correctness.\n4. Send/transfer documents to external partners through secure channel.\n5. Confirm receipt and document review by recipient.\n6. Log all creation, transmission, and receipt events in audit trail.\n7. Attempt to generate document with full card number—system must block or scrub and log error.\n8. Retrieve audit records for each document event and verify masking status.", + "expectedResult": "All external documents (agency/legal) contain only masked card (last 4 digits); secure transmission and acknowledgement completed. Audit log covers all document events. Masking is enforced at every stage; system blocks unmasked artifacts.", + "qualityAttribute": "masking, audit, document compliance, secure transmission, integration", + "rolesTested": "system, agency, legal staff", + "dataPoints": "external documents, masked card digits, recipient, audit log", + "integrationPoints": "agency system, legal system" + }, + { + "type": "functional", + "title": "Real-Time Notification Retry and Failure Recovery Mechanism Verification", + "description": "Validates the system’s ability to detect, log, and automate retry mechanisms for failed notifications at every lifecycle stage, with masking compliance.", + "testId": "TC-026", + "testDescription": "When a notification (reminder, overdue alert, collection, payment plan, agency, legal) fails to deliver due to network, channel, or recipient errors, the system must retry according to policy, record all attempts, and ensure every message contains only the card’s last 4 digits. If retries fail, escalation and administrator alert must occur with compliant audit logging.", + "prerequisites": "Account in any collection lifecycle state requiring notification; valid and invalid contact channels configured; retry policy set (e.g., 3 attempts); audit logging enabled.", + "stepsToPerform": "1. Trigger notification dispatch for account with valid contact method.\n2. Simulate network/channel failure causing notification to fail.\n3. System auto-retries notification as per policy.\n4. Each retry includes masked card number (last 4 digits only).\n5. On persistent failure, trigger escalation workflow for manual intervention.\n6. Log every attempt, retry, and failure event in audit log.\n7. Confirm administrator is alert via error report/notification.\n8. Verify masking enforcement in all attempted and failed notifications.\n9. Attempt to retrieve failed notification payload and verify no full card number exposure.\n10. Validate audit log for tracking all retries, masking, escalation, and recipient role.", + "expectedResult": "Notification failures are detected, retried, and logged with masking compliance. Persistent issues escalate to administrator. Masked card digits appear in all events. No full card data is exposed in any notification or log.", + "qualityAttribute": "retry handling, masking, error management, audit compliance", + "rolesTested": "cardholder, administrator, system", + "workflowCoverage": "reminder, overdue, collection, payment plan, agency, legal", + "retryPolicy": "up to 3 retries, escalation after failure" + }, + { + "type": "boundary", + "title": "Dynamic Due Date Adjustment and Notification Window Compliance", + "description": "Tests system response to last-minute due date changes and ensures correct recalculation of notification windows, masking enforcement, and suppression of invalid reminders.", + "testId": "TC-027", + "testDescription": "As a cardholder whose payment due date is amended (extended/shortened) during the notification window, I want to receive correct reminders reflecting only the last 4 card digits, and avoid duplicate or outdated notifications. System must recalculate notification timing, enforce masking, and properly log all changes.", + "prerequisites": "Active credit card account; original payment due date in imminent reminder window; notification workflow enabled; masking logic active; audit log configured.", + "stepsToPerform": "1. Set up account with original payment due date in 7 days.\n2. Issue reminder notification (masked last 4 digits only).\n3. Change payment due date (extend by 3 days).\n4. System recalculates reminder window and adjusts subsequent reminders.\n5. Trigger new reminder notification per updated schedule.\n6. Attempt to send reminder using obsolete schedule—system must suppress.\n7. Audit log records both the change and suppression events.\n8. Verify all reminders contain only the last 4 digits.\n9. Attempt notification resend for non-current due date—system blocks and logs error.\n10. Validate audit for timing, masking, and suppression logic.", + "expectedResult": "Notifications adapt to due date changes; only in-window reminders are sent with last 4 digits. Duplicates/outdated reminders are suppressed and logged. Audit trail captures all events.", + "qualityAttribute": "dynamic timing, masking, boundary handling, audit", + "rolesTested": "cardholder, system", + "boundaryChecks": "due date adjustment, notification window recalculation" + }, + { + "type": "negative", + "title": "Payment Plan Terms Violation and Legal Escalation Prevention", + "description": "Verifies system behavior when a payment plan is breached but the violation does NOT meet legal escalation criteria, ensuring proper workflow containment and masking.", + "testId": "TC-028", + "testDescription": "If a cardholder fails to meet installment terms for a payment plan but the breach does not trigger legal escalation (e.g., minor delay, partial payment), the system must issue properly masked collection notifications and prevent premature legal action or agency transfer. Audit logs must reflect all events and masking adherence.", + "prerequisites": "Account on payment plan; installment due; simulated minor violation (late/partial payment not qualifying for legal escalation); audit and masking logic configured; legal escalation thresholds defined.", + "stepsToPerform": "1. Cardholder accepts payment plan with last 4 digits masked.\n2. Simulate late or partial installment payment below escalation threshold.\n3. System detects violation and triggers internal collection workflow.\n4. Generate collection notification with strict masking for last 4 digits.\n5. Prevent legal escalation or agency hand-off.\n6. Audit log details violation, notification issuance, and containment.\n7. Attempt to escalate to legal/agency prematurely—system blocks and logs error.\n8. Subsequent regular reminders sent with last 4 digits only.\n9. Validate all communications, logs, and workflow steps for compliance.", + "expectedResult": "Payment plan breach results in correctly masked collection notifications. No premature escalation occurs. Audit logs cover all workflow events. Masking is enforced throughout.", + "qualityAttribute": "workflow branching, masking, negative path handling, audit", + "rolesTested": "cardholder, system", + "workflowCoverage": "payment plan, collection, legal/agency suppression" + }, + { + "type": "functional", + "title": "User-Initiated Escalation Request and Immediate Agency/Legal Notification", + "description": "Validates the ability for a cardholder to proactively request escalation (e.g., dispute or voluntary legal process), triggering agency/legal workflow and immediate communication—masked per rules.", + "testId": "TC-029", + "testDescription": "A cardholder may request voluntary escalation for dispute resolution, debt restructuring, or legal intervention. System must support user-initiated escalation, generate required notifications/documents with only last 4 digits shown, and audit all actions. Communication must reach agency/legal staff with proper role handling and masking.", + "prerequisites": "Delinquent account with self-service escalation feature enabled; cardholder authentication in place; agency/legal endpoints active; audit and masking logic ready.", + "stepsToPerform": "1. Cardholder logs into portal and initiates escalation request (dispute/debt restructure/legal).\n2. System validates request, confirms role, and prepares escalation workflow.\n3. Generate notification/document for agency/legal channel (last 4 digits only).\n4. Immediately transmit to agency/legal team and cardholder.\n5. Audit log captures initiation, transmission, recipient roles, and masking.\n6. Confirm response/acknowledgment from agency/legal staff.\n7. Review returned documents/messages for masking compliance.\n8. Attempt escalation with full card number—system blocks and logs error.\n9. Validate audit log for completeness and compliance.", + "expectedResult": "User-initiated escalations result in properly masked communications to all parties. Audit logs cover initiation, transmission, and response. No full card number appears in any notification or external document.", + "qualityAttribute": "role handling, workflow initiation, masking, audit, compliance", + "rolesTested": "cardholder, agency, legal staff, system", + "integrationPoints": "self-service portal, agency/legal workflow" + }, + { + "type": "end-to-end", + "title": "Lifecycle Interruption and Recovery after System Outage with Masking Assurance", + "description": "Simulates a system outage during active collection lifecycle workflows and validates the proper recovery, state re-synchronization, and masking enforcement across all recovered communications.", + "testId": "TC-030", + "testDescription": "When the system experiences interruption (e.g., unplanned outage, scheduled maintenance) during overdue, collection, payment plan, or escalation phases, all in-progress communications and state transitions must recover and resume with only last 4 digits of card exposed. Audit logs must record outage, recovery, and any affected workflow events.", + "prerequisites": "Credit card accounts in active collection lifecycle stages; planned/unplanned system outage or failover scenario initiated; audit monitoring and masking enforcement active.", + "stepsToPerform": "1. Accounts actively in overdue, collection, or agency/legal workflow.\n2. System outage or maintenance event occurs; pending notifications/data hand-offs paused.\n3. System recovers, restores pending workflow steps.\n4. Resume and dispatch all recovered notifications and documents (last 4 digits only).\n5. Audit log captures outage period, paused actions, recovery events, and resumed communications.\n6. Validate masking in all post-recovery messages (no accidental exposure from interrupted workflows).\n7. Confirm no duplicate or out-of-order notifications upon recovery.\n8. Attempt to retrieve message logs during outage; verify suppression and masking.\n9. Validate regulatory compliance in all recovery and restart events.", + "expectedResult": "Collection workflow resumes after outage with masked communications and correct state. Audit logs capture all affected events. No full card data is exposed in any message or log during or after recovery. Notification sequence is correct and non-duplicated.", + "qualityAttribute": "availability, masking, audit, workflow continuity, recovery compliance", + "rolesTested": "cardholder, system, agency, legal staff, administrator", + "stateTransitions": "outage, paused, resumed, completed" + } +] \ No newline at end of file diff --git a/functional_tests/ZBIO-5213/ZBIO-5213.xlsx b/functional_tests/ZBIO-5213/ZBIO-5213.xlsx new file mode 100644 index 0000000..e6c7c32 Binary files /dev/null and b/functional_tests/ZBIO-5213/ZBIO-5213.xlsx differ diff --git a/functional_tests/ZBIO-5213/ZBIO-5213.yaml b/functional_tests/ZBIO-5213/ZBIO-5213.yaml new file mode 100644 index 0000000..6f2bd15 --- /dev/null +++ b/functional_tests/ZBIO-5213/ZBIO-5213.yaml @@ -0,0 +1,805 @@ +openapi: 3.0.3 +info: + title: Credit Card Collection Compliance API + version: 1.0.0 + description: > + API specification for compliant, masked, and auditable credit card collection workflows, notifications, state transitions, + agency/legal integrations, masking enforcement and error handling as per regulatory and business mandates. + +servers: + - url: https://api.cards-collection.example.com/v1 + +security: + - bearerAuth: [] + +components: + securitySchemes: + bearerAuth: + type: http + scheme: bearer + bearerFormat: JWT + parameters: + accountId: + in: path + name: account_id + required: true + schema: + type: string + description: The unique identifier for the cardholder account. + cardId: + in: path + name: card_id + required: true + schema: + type: string + description: The card entity identifier. + schemas: + Notification: + type: object + properties: + account_id: + type: string + example: 12345 + channel: + type: string + enum: [email, sms, in-app, document] + example: email + cardholder_name: + type: string + example: Alice Smith + last_4: + type: string + pattern: '^\d{4}$' + example: 1881 + due_date: + type: string + format: date + example: 2024-07-15 + due_amount: + type: string + example: "$500.00" + overdue_amount: + type: string + example: "$300.00" + late_fee: + type: string + example: "$10.00" + message: + type: string + example: "Your card ending 1881 has a payment due of $500.00 on 2024-07-15." + recipient_role: + type: string + enum: [cardholder, agency, legal_staff, administrator] + required: + - account_id + - channel + - last_4 + AuditLog: + type: object + properties: + event_type: + type: string + enum: [notification, state_transition, masking_error, transmission, payment_attempt, access_denied, error] + account_id: + type: string + cardholder_name: + type: string + last_4: + type: string + recipient: + type: string + role: + type: string + timestamp: + type: string + format: date-time + compliance: + type: object + properties: + masking_enforced: + type: boolean + regulatory_check: + type: string + enum: [passed, failed] + details: + type: string + required: [event_type, account_id, last_4, timestamp] + CollectionAgencyTransmission: + type: object + properties: + balance_due: + type: string + example: "$800.00" + cardholder_name: + type: string + last_4_digits: + type: string + status: + type: string + enum: [sent, ack, error] + error: + type: string + nullable: true + required: [balance_due, cardholder_name, last_4_digits] + Escalation: + type: object + properties: + account_id: + type: string + escalated_state: + type: string + enum: [collection, agency, legal, active] + last_4: + type: string + transition: + type: string + enum: [escalate, deescalate] + status: + type: string + enum: [success, error] + error: + type: string + nullable: true + required: [account_id, escalated_state, last_4, transition, status] + NotificationPreference: + type: object + properties: + channel: + type: string + enum: [email, sms, in-app, document] + enabled: + type: boolean + required: + - channel + - enabled + PaymentPlanProposal: + type: object + properties: + account_id: + type: string + last_4: + type: string + proposal_terms: + type: object + properties: + installment_amount: + type: string + example: "$150.00" + installment_date: + type: string + format: date + required: [installment_amount, installment_date] + status: + type: string + enum: [sent, accepted, rejected, breached, error] + error: + type: string + nullable: true + required: [account_id, last_4, proposal_terms, status] + +paths: + /accounts/{account_id}/notifications/reminder: + post: + summary: Send payment due reminder notification (masked, auditable) + description: > + Sends a masked notification to the cardholder via the specified channel, + enforcing PII masking (last 4 digits only), with audit logging and compliance checks. + security: + - bearerAuth: [] + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + channel: + type: string + enum: [email, sms, in-app] + due_date: + type: string + format: date + due_amount: + type: string + cardholder_name: + type: string + last_4: + type: string + pattern: '^\d{4}$' + required: [channel, due_date, due_amount, cardholder_name, last_4] + responses: + '201': + description: Reminder notification delivered successfully (masked) + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '400': + description: Invalid request (bad input, out-of-window, or duplicate) + '403': + description: Unauthorized or masking violation + '409': + description: Duplicate notification blocked + /accounts/{account_id}/notifications/overdue: + post: + summary: Send overdue balance alert (masked, auditable) + description: > + Sends overdue alert to cardholder if unpaid/partial status, includes masking (last 4), overdue amount, + and audit of alert/state change. + security: + - bearerAuth: [] + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + cardholder_name: + type: string + channel: + type: string + enum: [email, sms, in-app] + overdue_amount: + type: string + last_4: + type: string + pattern: '^\d{4}$' + required: [cardholder_name, channel, overdue_amount, last_4] + responses: + '201': + description: Overdue notification sent (masked) + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '400': + description: Invalid status or masking error + '403': + description: Unauthorized + '409': + description: Duplicate or state prevented + + /accounts/{account_id}/notifications/collection: + post: + summary: Send collection notification at defined delinquency boundary with dynamic fee + description: > + Sends collection notification if overdue/delinquency threshold met. Includes masked card (last 4), overdue amount, late fee, + and complete audit logging. + security: + - bearerAuth: [] + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + channel: + type: string + enum: [email, sms, in-app, document] + overdue_amount: + type: string + late_fee: + type: string + last_4: + type: string + pattern: '^\d{4}$' + delinquency_days: + type: integer + required: [channel, overdue_amount, late_fee, last_4, delinquency_days] + responses: + '201': + description: Collection notification sent (masked) + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '400': + description: Not yet delinquent, masking or input error + '409': + description: Already sent or out-of-window + + /agency/transmit: + post: + summary: Collection agency data hand-off with masking & compliance + description: > + Securely transmits masked (last 4 only) debtor data to agency endpoint. Fully auditable and errors handled. + security: + - bearerAuth: [] + requestBody: + required: true + content: + application/json: + schema: + $ref: '#/components/schemas/CollectionAgencyTransmission' + responses: + '200': + description: Agency acknowledged receipt (masked data) + content: + application/json: + schema: + $ref: '#/components/schemas/CollectionAgencyTransmission' + '202': + description: Data transmission accepted, acknowledgment pending + '400': + description: Data or masking error + '409': + description: Integration error or rejected by agency + + /accounts/{account_id}/escalation: + post: + summary: Escalate/de-escalate collection workflow state (masked, auditable) + description: > + Trigger escalation or de-escalation to agency/legal, enforcing masking and compliance, with full audit log. + security: + - bearerAuth: [] + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + $ref: '#/components/schemas/Escalation' + responses: + '200': + description: Escalation/de-escalation completed and logged + content: + application/json: + schema: + $ref: '#/components/schemas/Escalation' + '400': + description: Invalid transition, masking, or account status + '404': + description: Account not found + + /accounts/{account_id}/notification-preferences: + get: + summary: Retrieve notification channel opt-in/out preferences for cardholder + responses: + '200': + description: Current channel preferences + content: + application/json: + schema: + type: array + items: + $ref: '#/components/schemas/NotificationPreference' + '403': + description: Unauthorized + put: + summary: Set notification channel opt-in/out preferences for cardholder (masked) + requestBody: + required: true + content: + application/json: + schema: + type: array + items: + $ref: '#/components/schemas/NotificationPreference' + responses: + '200': + description: Preferences updated, audit logged + content: + application/json: + schema: + type: array + items: + $ref: '#/components/schemas/NotificationPreference' + '400': + description: Invalid request + '403': + description: Unauthorized + + /accounts/{account_id}/payment-plan/proposal: + post: + summary: Propose payment plan enrollment if eligible (masked, compliant) + description: > + Issues a payment plan proposal to an overdue cardholder within configured threshold with last 4 masking. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + overdue_days: + type: integer + min_days: + type: integer + max_days: + type: integer + last_4: + type: string + proposal_terms: + type: object + properties: + installment_amount: + type: string + installment_date: + type: string + required: [overdue_days, min_days, max_days, last_4] + responses: + '201': + description: Payment plan proposal sent and audit logged + content: + application/json: + schema: + $ref: '#/components/schemas/PaymentPlanProposal' + '400': + description: Not eligible or input/masking error + '409': + description: Duplicate or policy violation + + /accounts/{account_id}/notifications/retry: + post: + summary: Retry notification on failure (masked, retriable, auditable) + description: > + Retries past notification delivery on transient error, enforcing masking and policy retry limit. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + stage: + type: string + example: overdue + contact: + type: string + retry_limit: + type: integer + last_4: + type: string + required: [stage, contact, retry_limit, last_4] + responses: + '200': + description: Retry performed or escalated, audit logged + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '202': + description: Retry queued + '400': + description: Invalid parameters or masking error + '429': + description: Retry limit reached + + /accounts/{account_id}/audit-log: + get: + summary: Retrieve all audit logs for the account (masked, compliant) + parameters: + - $ref: '#/components/parameters/accountId' + responses: + '200': + description: Audit log retrieved + content: + application/json: + schema: + type: array + items: + $ref: '#/components/schemas/AuditLog' + '403': + description: Unauthorized access + /audit-log: + get: + summary: Retrieve audit logs (multiple accounts; admin/legal use only) + description: > + Retrieves audit logs with proper masking and privilege checks. Access denied and logged for non-authorized. + parameters: + - in: query + name: account_id + schema: + type: string + - in: query + name: event_type + schema: + type: string + responses: + '200': + description: Audit log retrieved (admin/legal only) + content: + application/json: + schema: + type: array + items: + $ref: '#/components/schemas/AuditLog' + '403': + description: Unauthorized/privilege violation + + /accounts/{account_id}/documents/generated: + post: + summary: Generate and transmit external/legal documents (masked) + description: > + Generates a document (agency/legal forms) containing ONLY last 4 digits and transmits securely; blocks/logs error on unmasked data. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + recipient_type: + type: string + enum: [cardholder, agency, legal_staff, administrator] + last_4: + type: string + required: [recipient_type, last_4] + responses: + '201': + description: Document generated, transmitted, audit logged + '400': + description: Masking error (full card in document), rejected + + /accounts/{account_id}/notifications/multichannel: + post: + summary: Multi-channel notification delivery (with role masking) + description: > + Delivers notification to recipient via specified channel, role, and workflow stage with proper masking. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + channel: + type: string + stage: + type: string + role: + type: string + enum: [cardholder, agency, legal_staff, administrator] + cardholder_name: + type: string + last_4: + type: string + required: [channel, stage, role, cardholder_name, last_4] + responses: + '201': + description: Notification sent, audit logged + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '400': + description: Masking or template error + + /accounts/{account_id}/notifications/duplicate-prevention: + post: + summary: Prevent duplicate/out-of-window notifications + description: > + Validates and suppresses duplicate/out-of-window reminders per configured window and masking. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + due_date: + type: string + window_min: + type: integer + window_max: + type: integer + days_before_due: + type: integer + last_4: + type: string + duplicate_attempt: + type: boolean + required: [due_date, window_min, window_max, days_before_due, last_4] + responses: + '201': + description: Notification sent or blocked as duplicate; audit/log + '409': + description: Duplicate/out-of-window blocked + + /accounts/{account_id}/lifecyle/state: + patch: + summary: Advance or recover collection workflow state (incl. outage handling) + description: > + Advance, resume or recover workflow state (reminder, overdue, collection, plan, agency, legal), ensuring masking and audit + during transitions, including after system outage. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + action: + type: string + enum: [advance, resume, recover] + last_4: + type: string + required: [action, last_4] + responses: + '200': + description: State advanced/recovered; notifications and logs comply + '400': + description: Masking/compliance failure + + /accounts/{account_id}/notifications/due-date-adjustment: + post: + summary: Adjust due date and recalculate notification windows (masked) + description: > + Handles due-date changes, recalculates reminder windows, avoids obsolete/duplicate reminders, audits masking. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + original_due_date: + type: string + new_due_date: + type: string + last_4: + type: string + required: [original_due_date, new_due_date, last_4] + responses: + '200': + description: Reminder window recalculated, notifications adjusted + '400': + description: Invalid/masking error + + /accounts/{account_id}/notifications/collection-update-balance: + post: + summary: Send updated collection notification after real-time partial payment + description: > + Updates overdue balance, issues new collection notification using masking, blocks stale/out-of-balance attempts. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + overdue_amount: + type: string + payment_amount: + type: string + last_4: + type: string + required: [overdue_amount, payment_amount, last_4] + responses: + '201': + description: Updated notification delivered; audit logged + '409': + description: Stale/incorrect balance notification blocked + + /accounts/{account_id}/notifications/pii-scan: + post: + summary: Scan for PII/masking violation before notification transmission + description: > + Checks outgoing notification for full card or PII exposure; blocks and logs if masking fails. + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + notification_payload: + type: string + contact: + type: string + retry_limit: + type: integer + required: [notification_payload, contact, retry_limit] + responses: + '400': + description: Masking/PII failure blocked and audit logged + '409': + description: Transmission failure, retry logic applied + + /accounts/{account_id}/payment-plan/action: + post: + summary: Accept, refuse, or breach payment plan proposal (masked, auditable) + description: > + Accept/refuse/breach a payment plan, all masked; triggers proper workflow branch, logs compliance and masking. + parameters: + - $ref: '#/components/parameters/accountId' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + cardholder_name: + type: string + response_type: + type: string + enum: [accept, partial_accept, refuse, breach] + last_4: + type: string + required: [cardholder_name, response_type, last_4] + responses: + '200': + description: Branch executed, audit logged + '400': + description: Invalid state, masking, or branch logic error + + /accounts/{account_id}/fees-breakdown: + get: + summary: Retrieve itemized collection fees and charges (masked) + parameters: + - $ref: '#/components/parameters/accountId' + responses: + '200': + description: Fee breakdown provided with masking + content: + application/json: + schema: + type: object + properties: + last_4: + type: string + itemized_fees: + type: array + items: + type: object + properties: + type: + type: string + amount: + type: string + authorized: + type: boolean + headers: + X-Masked: + description: Always true; full card never included + schema: + type: boolean + '403': + description: Unauthorized/unauthenticated, audit and block + +tags: + - name: Notification + description: Masked and auditable notifications (reminder, overdue, collection, multi-channel, retry, duplicate prevention) + - name: Escalation + description: Escalation/de-escalation, agency/legal hand-off, masking enforcement + - name: PaymentPlan + description: Payment plan proposal, acceptance/refusal/breach + - name: Preferences + description: Opt-in/out notification channel management + - name: Audit + description: Regulatory, masking, and workflow audit logging + - name: ExternalDocument + description: Secure document/payload generation and transmission + - name: AccountState + description: State transition; lifecycle advancement, outage recovery + - name: FeesBreakdown + description: Itemized fee/charge breakdown retrieval (masked) + - name: Performance + description: Bulk dispatch and load/performance requirements +