diff --git a/functional_tests/README.md b/functional_tests/README.md index 1c972b2..6d50004 100644 --- a/functional_tests/README.md +++ b/functional_tests/README.md @@ -65,3 +65,20 @@ --- +**Execution Date:** 4/27/2026, 7:28:44 AM + +**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..a214e53 --- /dev/null +++ b/functional_tests/ZBIO-5213/.roost/roost_metadata.json @@ -0,0 +1,19 @@ +{ + "project": { + "name": "ZBIO-5213", + "created_at": "2026-04-27T07:28:44.376Z", + "updated_at": "2026-04-27T07:28:44.376Z" + }, + "files": { + "input_files": [ + { + "fileName": "ZBIO-5213.txt", + "fileURI": "/var/tmp/Roost/RoostGPT/demo-functional-test/41909e28-4686-472a-9026-216085391028/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..8bf645a --- /dev/null +++ b/functional_tests/ZBIO-5213/ZBIO-5213.csv @@ -0,0 +1,31 @@ +Credit card due collection lifecycle transitions and masking +Overdue balance escalation fee calculation and integration error handling +Role-based notification trigger and masking enforcement +Notification generation, multi-channel delivery, and masking +User actions and system state transitions for payment plan and collections +Notification misdelivery and masked correction workflow +Payment plan proposal eligibility and masking at boundary values +Collection agency handoff integration failure and masking +Legal action document creation, notification, masking, and access control +Invalid payment input and secure error messaging workflow +Notification suppression upon early payment and masking +Manual override of collection escalation and masking +Disputed overdue amount and temporary suspension with masking +Parallel due and collection workflows for multiple cards per user +Post-legal closure notification, retention and masking enforcement +End-to-end UI masking validation for overdue and escalation journey +Audit log and retention validation for all states, actions, and masked digits +Penalty, fee, and interest assessment with boundary and negative values +Integration error handling, retry, and masked comm/logs +Payment plan, partial payment, reversal, recovery and masking +Sequential overdue notices, timing, masking, and suppression logic +Localization/regulatory formatting for multilingual notifications with masked digits +Dynamic role change handling, notification masking, and access control +Retroactive fee change, notification content update, and full masking +Third-party broker (Twilio, SendGrid) notification consistency and masking +Delayed payment after collection notification and suppression of agency escalation +Notification template editing and preview masking +Linked loan repayment impacting overdue card state, masking, notification suppression +Legal case reopening after customer appeal with masked communication validation +User communication consent withdrawal with notification suppression and masking +Collection entity API operations with masking and compliance checks \ 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..04338ed 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..d859bec --- /dev/null +++ b/functional_tests/ZBIO-5213/ZBIO-5213.feature @@ -0,0 +1,462 @@ +Feature: Comprehensive Credit Card Due and Collection Workflow Masking, Compliance, Notification, and State Management + + # Background: Common test setup for API and UI scenarios + Background: + Given the system base URL is configured + And authorization, notification, and agency integrations are enabled + And the test cardholder(s) and staff roles exist in the environment + And audit log and masking policy enforcement are enabled + + # End-to-End Workflow + @e2e @ui @api + Scenario Outline: Credit card due collection lifecycle transitions and masking + Given an existing credit card account ending with upcoming payment due + And eligible workflow and notification integration are enabled + When the system sends a due reminder notification for the account + Then the notification shows only the last 4 digits '' and never full card number + When due date passes with no payment, the system triggers overdue alert and calculates additional charges + Then overdue notification is sent with masked card digits and fee calculation is validated + When escalation threshold is reached, formal collection notification is sent with last 4 digits only + Then overdue balance and late fees are correctly calculated and masked in the communication + When continued non-payment is simulated, external collection agency workflow is triggered + Then handoff communication is confirmed, card data is redacted and masked + When a payment plan proposal is offered, customer accepts and makes initial payment as per plan + Then workflow transitions, fee calculation, and masking are validated + When default/dispute occurs after plan, legal escalation is triggered and documents are generated + Then all documents and notifications show masked digits, role-based actions are respected + When legal closure or recovery completes, system state is updated, notifications sent, and audit log reviewed + Then audit trail contains only masked card PII and compliance requirements are met + + Examples: + | card_last4 | + | 1234 | + + # Boundary Value and Negative Path + @api @ui + Scenario Outline: Overdue balance escalation fee calculation and integration error handling + Given account with overdue balance and escalation threshold logic enabled + When the system triggers due/overdue notification and/or escalation + Then notification/communication shows only masked card digits, calculation aligns with boundary value, and error handling is user-friendly and masked + When staff user applies one-time fee waiver or override + Then content and logs reflect override, masking, and correct recalculation + When agency handoff is attempted and integration is + Then outcome is logged, notifications are masked, and system recovers gracefully + + Examples: + | balance | integration_state | + | 0 | up | + | -10 | up | + | 500 | down | + | 10000 | down | + | Max | up | + + # Role-Based Access & Masking + @rbac @ui @api + Scenario Outline: Role-based notification trigger and masking enforcement + Given user of role with assigned overdue account ending + When user attempts to view or trigger notification/action in the collection workflow + Then permission, access control, and masking enforcement apply per role + When unauthorized action is attempted (view/escalate/download) + Then system blocks action, displays masked error, and logs event + + Examples: + | role | card_last4 | + | Customer | 9876 | + | Bank Staff | 9876 | + | Collection Agent | 9876 | + | Legal Handler | 9876 | + | System Admin | 9876 | + | Unauthorized User | 9876 | + + # Notification Content Delivery & Masking + @notify @ui @api + Scenario Outline: Notification generation, multi-channel delivery, and masking + Given overdue or collection event occurs for card ending with communication channels enabled + When the system sends notification via + Then notification content, formatting, and masking are validated per channel and regulatory requirement + When delivery fails or is misaddressed, error handling and masking are enforced + When retry/fallback is performed, masking persists and error logs are compliant + And downloadable documents are inspected for masking + + Examples: + | card_last4 | channel | + | 2468 | SMS | + | 2468 | Email | + | 2468 | UI | + | 2468 | Download | + + # Decision Table for Payment Plan & State Transition + @state + Scenario Outline: User actions and system state transitions for payment plan and collections + Given overdue account ending at state + When user action is performed + Then system transitions state to , recalculates fee, sends masked notification, and logs event + + Examples: + | card_last4 | state | user_action | next_state | + | 5555 | Overdue | Pay in full | Current | + | 5555 | Overdue | Pay partial | Overdue | + | 5555 | Collection | Accept plan | Payment Plan | + | 5555 | Collection | Decline plan | Agency | + | 5555 | Agency | Pay after escalation | Recovered | + | 5555 | Legal | Resolve dispute | Closed | + + # Notification Misdelivery & Correction Negative Path + @negui @ui + Scenario Outline: Notification misdelivery and masked correction workflow + Given cardholder profile with incorrect contact information for card ending + When due reminder notification is sent and delivered to wrong user/contact + Then recipient reports the issue and system support workflow is triggered + When contact is updated and notification is re-sent + Then notification content and audit logs reflect masking, error, and compliance + + Examples: + | card_last4 | incorrect_contact | + | 4321 | wrong_email | + + # Payment Plan Boundary & Eligibility + @ppboundary @api @ui + Scenario Outline: Payment plan proposal eligibility and masking at boundary values + Given overdue account with balance for card ending + When system attempts to generate payment plan proposal + Then plan is , notification is sent or suppressed, and only last 4 digits shown + When plan is accepted or rejected as user + Then notification, logs, and audit trail reflect outcome, masking, and compliance + + Examples: + | balance | plan_status | card_last4 | + | 0 | ineligible | 6543 | + | 49 | ineligible | 6543 | + | 500 | eligible | 6543 | + | 100000 | eligible | 6543 | + + # Collection Agency Integration Failure + @agencyfail @api + Scenario Outline: Collection agency handoff integration failure and masking + Given account in collection escalation state for card ending + And collection agency system integration is + When system triggers agency handoff + Then failure is logged, masked notifications sent to all parties, and retry/escalation path proceeds + When integration recovers, handoff is completed, logs and outputs remain masked + + Examples: + | card_last4 | integration_state | + | 1212 | down | + | 1212 | up after retry | + + # Legal Escalation, Document Generation & Access + @legal @api @ui + Scenario Outline: Legal action document creation, notification, masking, and access control + Given account in legal-eligible state for card ending and legal handler available + When legal action is initiated and documents generated + Then all notices, headers, footers, annex (UI/PDF/Download) show only masked digits + When access attempt by to legal documents occurs + Then system enforces access control and masking per regulatory policy + + Examples: + | card_last4 | role | + | 4444 | Legal Handler | + | 4444 | Customer | + | 4444 | Unauthorized User | + | 4444 | Collection Agent| + | 4444 | Bank Staff | + + # Invalid User Input and Monetary Calculation Error Handling + @dataval @ui + Scenario Outline: Invalid payment input and secure error messaging workflow + Given cardholder logs into portal for account ending + When user enters payment amount + Then UI blocks invalid input, shows error message with masking, and logs action + When staff corrects overdue or fee miscalculation + Then user receives updated notification, masking is preserved + + Examples: + | card_last4 | amount | + | 2222 | -50 | + | 2222 | 0 | + | 2222 | max+1 | + | 2222 | threshold | + + # Notification Suppression on Early Payment + @supp @ui + Scenario Outline: Notification suppression upon early payment and masking + Given due reminder is scheduled for card ending + When cardholder makes early payment before reminder date + Then system updates account state, suppresses all scheduled notifications, and sends masked receipt + When attempt to trigger overdue reminder is made + Then operation is suppressed, audit log and communication reflect masking + + Examples: + | card_last4 | + | 5678 | + + # Escalation Manual Override and Audit Compliance + @manual @api @ui + Scenario Outline: Manual override of collection escalation and masking + Given overdue account at escalation threshold for card ending + When bank staff applies manual hold/override with justification + Then system cancels/delays collection notification, logs override with masked digits + When customer receives revised notification + Then only masked digits are shown + When manual handoff is attempted, operation is blocked and error is masked/logged + + Examples: + | card_last4 | + | 9090 | + + # Dispute Handling and State Freeze + @dispute @ui @api + Scenario Outline: Disputed overdue amount and temporary suspension with masking + Given overdue account ending and active collection/notification workflow + When customer raises dispute on overdue fee + Then system freezes escalation, halts notifications, all logs and comms show masked digits + When dispute is resolved as + Then customer/staff receive appropriate masked notification and workflow resumes/adjusts per policy + + Examples: + | card_last4 | resolution | + | 5555 | approve | + | 5555 | adjust | + | 5555 | reject | + + # Multiple Cards, Parallel Workflows, Cross-Masking + @multi @ui @api + Scenario Outline: Parallel due and collection workflows for multiple cards per user + Given cardholder with accounts ending and in separate workflows + When system triggers notifications for each card + Then each comm displays correct masked digits, no mixing of card data + When cross-notification error is simulated + Then system blocks/corrects, all logs/comms remain masked and segregated + + Examples: + | card_last4a | card_last4b | + | 1010 | 2020 | + + # Post-Legal Closure Communication and Retention + @postclose @ui @api + Scenario Outline: Post-legal closure notification, retention and masking enforcement + Given account ending completed legal closure + When system generates final closure notification/documents for all parties + Then all communications use only last 4 digits and system disables further action/workflow + When audit/download/archive is performed + Then artifacts are masked and retained as per regulatory timelines + + Examples: + | card_last4 | + | 9898 | + + # Portal UI Masking Validation on Screens and Downloadable Documents + @uimask @ui + Scenario Outline: End-to-end UI masking validation for overdue and escalation journey + Given cardholder logs in and views dashboard for card ending + When user navigates to documents section and downloads PDF/statement/notice + Then content and file name show only masked digits, UI, popups, browser titles remain masked + When account escalates to overdue, collection, and legal states + Then each notification/download/UI display maintains masking compliance even in errors, logs, or deep-links + + Examples: + | card_last4 | + | 1111 | + + # Audit Log and Retention Enforcement + @audit @api @ui + Scenario Outline: Audit log and retention validation for all states, actions, and masked digits + Given overdue event occurs for account ending + When payment, escalation, agency handoff, and legal closure actions are performed + Then audit log records actor, timestamp, action, and only masked digits, no full PII + When record retention expires, attempt to download/export logs + Then access is denied or redacted beyond retention, masking remains enforced + + Examples: + | card_last4 | + | 2222 | + + # Fee and Penalty Calculation Accuracy with Boundaries and Negative Values + @fee @api @ui + Scenario Outline: Penalty, fee, and interest assessment with boundary and negative values + Given account due with balance for card ending + When state changes to overdue/collection/legal and fee calculation is triggered + Then calculation is mathematically correct, enforced within allowed boundaries; comms/audit show only masked digits + When bank staff applies override + Then recalculated amounts and all logs/notifications are masked and meet disclosure policy + + Examples: + | balance | card_last4 | + | 0 | 3333 | + | -10 | 3333 | + | threshold | 3333 | + | max | 3333 | + + # Integration Cross-Workflow Error Handling + @interr @api + Scenario Outline: Integration error handling, retry, and masked comm/logs + Given account in overdue/collection state for card ending + When notification server or agency integration experiences delay or failure + Then system retries, provides masked notifications/logs, de-duplicates repeated attempts, and masks all outputs + When integration restores, handoff/notification is completed and masking persists + + Examples: + | card_last4 | + | 6789 | + + # Payment Plan Acceptance, Partial Payment, Reversal Workflow + @planrv @ui @api + Scenario Outline: Payment plan, partial payment, reversal, recovery and masking + Given account ending receives payment plan offer + When customer makes partial payment then attempts reversal + Then system recovers plan state, sends masked notification/comm to all roles + When staff reviews audit log, masking and sequence are verified + When customer overpays, system updates schedule and sends masked updates + + Examples: + | card_last4 | + | 3333 | + + # Collection Notification Scheduling and Suppression + @sched @ui @api + Scenario Outline: Sequential overdue notices, timing, masking, and suppression logic + Given overdue account ending with notification schedule configured + When system sends overdue notifications at scheduled intervals and user pays during sequence + Then escalation is suppressed, all logs and notifications show correct masking, no invalid/late communication is sent + + Examples: + | card_last4 | + | 5678 | + + # Notification Content and Localization Validation + @loc @ui @api + Scenario Outline: Localization/regulatory formatting for multilingual notifications with masked digits + Given account ending triggers overdue or collection event with locale + When notification is generated and sent in + Then content, regulatory text, and masking for card digits are validated per locale + When unsupported locale is assigned, fallback and masking rules apply, logs and previews are validated + + Examples: + | card_last4 | locale | + | 2468 | Spanish | + | 2468 | German | + | 2468 | French | + | 2468 | English | + + # Access Control and Role Revocation + @rbac2 @ui @api + Scenario Outline: Dynamic role change handling, notification masking, and access control + Given collection agent or staff with assigned overdue account ending + When mid-workflow, admin revokes agent's access + Then all action attempts, notifications, downloads are blocked or masked as per policy + When access is restored, workflow resumes, masking persists at all outputs + When illegal escalation is attempted after demotion, log and masked error are recorded + + Examples: + | card_last4 | + | 6789 | + + # Retroactive Fee Recalculation & Communication Update + @retro @api @ui + Scenario Outline: Retroactive fee change, notification content update, and full masking + Given overdue account ending assessed with original late fee and regulatory change occurs + When system recalculates fee and updates all historical and future comms/logs + Then all notifications, logs, and UI show correct fee and only masked digits + When system error occurs during recalculation, masking and compliance are validated + + Examples: + | card_last4 | + | 4444 | + + # Third-Party Notification Broker Integration and Masking Validation + @extint @api + Scenario Outline: Third-party broker (Twilio, SendGrid) notification consistency and masking + Given account ending triggers notification routed via + When payload, webhook, and delivery log are generated + Then only last 4 digits are present in all message payloads, logs, and outputs + When transmission fails, error logs and retries are masked and compliant + + Examples: + | card_last4 | broker | + | 1212 | Twilio | + | 1212 | SendGrid| + + # Delayed Payment Handling Before Agency Handoff + @time @ui @api + Scenario Outline: Delayed payment after collection notification and suppression of agency escalation + Given collection notification is sent for account ending , agency handoff scheduled + When customer makes full payment before escalation + Then system suppresses escalation, sends masked confirmation, and logs suppression + When staff/agent tries manual escalation, action is blocked and masking is enforced + + Examples: + | card_last4 | + | 2468 | + + # Notification Template Management and Masked Preview Error Handling + @template @ui + Scenario Outline: Notification template editing and preview masking + Given bank staff accesses notification template management UI for overdue/legal template + When staff edits template and inserts/updates masking token + Then preview shows only masked digit output (last 4), even during field error or missing data + When template error occurs, preview/log always masked; fallback template is used + When template is published or reverted, audit log masking is reviewed + + Examples: + | card_last4 | + | 8888 | + + # Cross-Product Payment and Collection Impact Notification + @xprod @api @ui + Scenario Outline: Linked loan repayment impacting overdue card state, masking, notification suppression + Given cardholder has overdue credit card ending and linked loan in arrears + When loan payment sufficiently credits card, system recalculates state and suppresses pending overdue/collection notifications + Then all notifications/confirmation comms show only masked digits, logs and statements are reviewed + When partial resolution leaves card overdue, subsequent notification reflects recalculated balance and masking + + Examples: + | card_last4 | + | 3579 | + + # Legal Case Appeal and Reopened Workflow + @appeal @ui @api + Scenario Outline: Legal case reopening after customer appeal with masked communication validation + Given legal case for card ending is closed + When customer appeals, legal handler approves reopening, system reinstates workflow and generates notices + Then all notifications, audit logs, reopened and closed chains reviewed for masking compliance + When customer responds (payment/dispute), system updates workflow and logs with masking + + Examples: + | card_last4 | + | 7410 | + + # Consent Withdrawal and Notification Suppression Validation + @consent @ui @api + Scenario Outline: User communication consent withdrawal with notification suppression and masking + Given customer navigates to notification preferences for card ending and withdraws consent + When system updates preferences and audit log + Then all digital comms are suppressed, fallback notice generated if required (masked), logs are reviewed + When consent is reinstated, future notifications enabled, masking checked on all outputs/history + + Examples: + | card_last4 | + | 9512 | + + # API Test Scenarios: CRUD Operations for Collection Entities (Example) + @api + Scenario Outline: Collection entity API operations with masking and compliance checks + Given the API base URL is '/api/collections' + And authorization token is set for + When I send a request to '/api/collections/' with payload + """ + { + "card_number": "", + "balance": , + "fee_applied": + } + """ + Then the response status should be + And the response should contain masked card number '' and no full card data + + Examples: + | role | method | entity_id | masked_card | balance | fee | status | + | Bank Staff| GET | 1001 | 5678 | 500 | 15 | 200 | + | System | POST | 1002 | 3333 | 1000 | 0 | 201 | + | Customer | PUT | 1003 | 2468 | 200 | 5 | 200 | + +# End of feature - all scenarios validated for masking, state, notification, audit, and regulatory compliance. diff --git a/functional_tests/ZBIO-5213/ZBIO-5213.json b/functional_tests/ZBIO-5213/ZBIO-5213.json new file mode 100644 index 0000000..1a140d6 --- /dev/null +++ b/functional_tests/ZBIO-5213/ZBIO-5213.json @@ -0,0 +1,417 @@ +[ + { + "type": "End-to-End Workflow", + "title": "Full Credit Card Due Collection Lifecycle - From Due Reminder to Legal Closure", + "description": "Covers the entire journey from due date reminder, overdue state, collection escalation, external agency handoff, payment plan offer, customer acceptance and payment, up to legal escalation on default.", + "testId": "ZBIO-5213-E2E-01", + "testDescription": "Validates all workflow transitions, notification deliveries, fee calculations, masking of card data, compliance requirements, user/business actions, and integration touchpoints across the lifecycle from initial due through legal action or recovery.", + "prerequisites": "Existing credit card account with an upcoming payment due, PII registered, eligible for workflow; notification and agency integration available; user with both customer and staff roles created", + "stepsToPerform": "1. Generate and send due reminder notification for card ending 1234, verify notification content and masking. 2. Wait until due date passes with no payment; system triggers overdue alert, verify additional charges are calculated and notification is sent with masked card digits. 3. At escalation threshold, send formal collection notification with last 4 digits only, and verify overdue balance/fees calculation. 4. Simulate continued non-payment; trigger external collection agency workflow, confirm handoff and data redaction/masking. 5. Offer payment plan proposal; customer views, accepts, and makes initial payment as per plan. 6. Simulate further default/dispute; escalate case to legal, generate legal documents, and ensure card masking is maintained throughout. 7. Confirm system logs/audit trails are recorded at all steps, contain PII only per policy. 8. Complete legal closure or recovery, confirm correct state update and post-action notifications to all roles. 9. Review all UI screens, communications, and downloadable documents for content, masking, and regulatory formatting.", + "expectedResult": "All notifications (email, SMS, UI, documents) show only last 4 digits of card, never full number; overdue/fee calculations are correct at each stage; successful workflow transitions between states; payment plan generation/acceptance works; integrations with agency/legal succeed or handle errors with appropriate messaging; all actions are properly logged with access/masking enforced; role-based actions are respected.", + "workflowsCovered": "Due Reminder, Overdue Alert, Collection Notification, Payment Plan Proposal, Collection Agency Handoff, Legal Action, Recovery/Closure", + "rolesInvolved": "Customer, Bank Staff, Collection Agent, Legal Handler", + "regulatoryChecks": "PCI DSS, data masking (all outputs), GDPR, record retention, notification formatting" + }, + { + "type": "Boundary Value and Negative Path", + "title": "Overdue Balance Escalation with Fee Waiver and Integration Failure Handling", + "description": "Tests edge cases with overdue balance at zero, negative, maximum, and threshold values. Simulates system/agency integration failure, and reviews fee waiver or override path.", + "testId": "ZBIO-5213-BV-NEG-02", + "testDescription": "Validates system handling of overdue/fees at all boundaries, attempts escalation with overridden or waived fees, and tests notification/collection agency system downtime scenarios.", + "prerequisites": "Accounts with diverse overdue balances (0, -10, 10000, max supported); staff role with override permissions setup; collection agency system set to time out for integration.", + "stepsToPerform": "1. Set account with due reminder at zero balance; confirm no notification is sent. 2. Set balance at negative amount; trigger due/overdue notification, verify correct communication and content. 3. Set balance at escalation threshold (e.g., $500); simulate overdue and collection notification, verify fee calculation. 4. Max out balance and trigger legal escalation, check system handles large values without error. 5. Staff user applies one-time fee waiver; resend notifications and confirm override reflected in content and logs. 6. Attempt agency handoff while integration is down; confirm error is logged, customer receives appropriate error/follow-up notification. 7. Retry agency handoff after integration recovers. 8. Check that no full card number is displayed in any error, notification, log, or data exchange. 9. Validate audit trail for all actions, including override and error events.", + "expectedResult": "Notifications align with overdue, fee values, and waivers; integration errors are user-friendly and comply with data masking; overrides are reflected in calculations and communications; system recovers from integration failures; no sensitive card data is exposed.", + "workflowsCovered": "Overdue Alert, Collection Notification, Collection Agency Handoff, Legal Action, Audit Log, Fee Waiver", + "rolesInvolved": "Customer, Bank Staff, System Admin", + "regulatoryChecks": "Data masking, PCI DSS compliance, audit requirements", + "boundaryValues": "0, negative, threshold, large, max" + }, + { + "type": "Role-Based Access & Audit", + "title": "Role-Based Notification Trigger, Masking, and Access Controls Enforcement", + "description": "Tests all role types for correct permissions to view/trigger notifications, including audit, masking, and exception paths.", + "testId": "ZBIO-5213-RBAC-03", + "testDescription": "Ensures notification triggers, content, and escalations are only accessible to authorized roles; audit and masking policies are enforced; attempts unauthorized actions.", + "prerequisites": "Users for all roles: customer, bank staff (collections ops), external collection agent, legal handler, system admin; standard and escalated accounts created for each case.", + "stepsToPerform": "1. Customer logs in and views overdue notice for card ending 9876; checks masking and ability to respond. 2. Bank staff triggers payment plan proposal; verifies confirmation and masking. 3. Collection agent logs into external portal, attempts to trigger notification—verify if permitted and content redacted correctly. 4. Legal handler reviews escalated account notifications and documents; confirms only last 4 digits displayed. 5. System admin attempts to access card data for closed case; verify strict masking and access denied for raw card fields. 6. Unauthorized user (wrong role) tries to escalate case to legal; confirm UI and API block, with proper error and masking. 7. Attempt to download all notification/audit logs as each role; verify data scope and masking. 8. Customer attempts to view external agency communication—check access restriction. 9. Bank staff views audit trail of actions taken, all roles and timestamps displayed, no PII violation.", + "expectedResult": "Only authorized users can trigger, view, or escalate notifications/workflows; all communications show last 4 digits only; unauthorized attempts fully blocked and properly logged; strict role-based masking enforced across UI, notifications, logs.", + "rolesInvolved": "Customer, Bank Staff, Collection Agent, Legal Handler, System Admin, Unauthorized User", + "regulatoryChecks": "PCI DSS, GDPR, role-based access, masking enforcement" + }, + { + "type": "Notification and Content Validation", + "title": "Notification Generation, Delivery, and Content Masking Across All Channels", + "description": "Verifies all notification types (reminder, overdue, collection, plan, legal), their contents, actual delivery (SMS/email/UI), PII compliance, retry/exception handling, and masking formatting.", + "testId": "ZBIO-5213-NOTIFY-04", + "testDescription": "Checks all outputs for format, masking, and delivery success/failure; includes content accuracy, retry logic, and formatting for legal/regulatory requirements.", + "prerequisites": "Cardholder with upcoming due, overdue, and in legal escalation; notification system and integration channels (email, SMS, UI, document generation) available and configured for all delivery paths.", + "stepsToPerform": "1. Generate and send due reminder via SMS, email, and UI portal; inspect for last 4 digits and correct formatting. 2. Trigger overdue alert and overdue collection notification for same card; verify delivery, content, and PII masking. 3. Simulate notification system failure on email, ensure fallback/alert is triggered, and successful retry is performed. 4. Generate payment plan proposal, delivered via multiple channels; verify contents and masking, review structured plan table alignment. 5. Collect all notifications and open each in UI, email, SMS; confirm consistency and compliance. 6. Examine notification logs and download documents for content and masking. 7. Simulate notification misdelivery (wrong user, out-of-date contact); verify masking and error handling. 8. Validate that legal notification formats comply with regulations (header, footer, redaction). 9. Review timing and sequencing of notifications for escalation, including time stamps and ID references.", + "expectedResult": "All notification types deliver via configured channels with proper format, PII masking (last 4 digits only), and clear instructions; system error handling and retry logic operates properly; no data leak; misaddressed notifications still compliant.", + "workflowsCovered": "All Notification Types, Legal Notification Formatting, Multi-Channel Delivery, Compliance", + "channelsCovered": "Email, SMS, UI, Downloadable Docs", + "regulatoryChecks": "PCI DSS, Communication Masking, Notification Content Requirements" + }, + { + "type": "Decision Table and State Transition", + "title": "Combinatorial User Responses and State Transitions for Payment Plan/Collections", + "description": "Tests all permutations of user actions (pay now, partial, reject plan, accept plan, dispute, default after plan, recovery payments after external escalation) and system state transitions for each case.", + "testId": "ZBIO-5213-STATE-05", + "testDescription": "Verifies that user actions and business rule outcomes lead to appropriate state transition, notification, fee calculation, masking, and log entries; covers reversals and exceptional logic.", + "prerequisites": "Cardholder in overdue, collection, and external/agency state; all payment flows enabled; dispute management configured; staff overrides and agency/legal handoff available.", + "stepsToPerform": "1. Customer receives overdue alert and pays in full; system transitions to current, overdue fees removed, confirm notification. 2. On receiving overdue, customer pays partial; system recalculates balance, sends follow-up alert with masked digits. 3. Collection notification triggers payment plan offer; customer accepts and makes initial payment; system splits balance, sends confirmation, and logs event. 4. Customer declines/ignores payment plan, triggers external agency handoff; verify notification content, handoff masking, and handoff logs. 5. Post agency escalation, customer makes late payment; system processes transition/attempt recovery, notifies agency and customer. 6. Dispute raised during collection/legal; system holds escalation, generates dispute receipt, notifies relevant parties with masked digits. 7. System/legal handler closes account post-judgment or recovery, notifies all roles; logs actions. 8. For each state change, verify logs, notifications, fees/charges, and masking. 9. Attempt reversal (post-escalation payment, dispute resolution), verify system and notification handling.", + "expectedResult": "All user decisions trigger correct system state transitions, audit/logs are maintained, notifications are accurate and masked, reversals and exceptional cases handled without exposing PII; agency/legal communications update correctly on transition.", + "workflowsCovered": "Payment Plan Generation, Collections, External Agency Handoff, Legal Action, Dispute Handling", + "statesTested": "Current, Due, Overdue, Collection, External, Legal, Recovered/Closed", + "decisionCombinations": "Pay in full, Pay partial, Accept/Reject plan, Dispute, Default after plan, Pay after escalation" + }, + { + "type": "Negative UI and Error Path", + "title": "Notification Misdelivery with Card Number Masking and User-Triggered Correction", + "description": "Ensures system handling and masking when due or overdue notifications are delivered to an incorrect user/contact, with user-initiated correction and regulatory compliance checks.", + "testId": "ZBIO-5213-NEGUI-06", + "testDescription": "Tests system response to misdelivered notification, masking enforcement, error messaging, correction workflow, and subsequent logs/comms, ensuring only last 4 digits are ever exposed.", + "prerequisites": "Active credit card accounts with legitimate and incorrect email/mobile contacts, notification channel enabled, customer with portal access, audit log enabled.", + "stepsToPerform": "1. Set up cardholder profile with an incorrect or outdated notification email address or mobile. 2. Generate due reminder notification, confirm delivery to wrong user/contact. 3. Recipient/user reports incorrect notification through portal or support. 4. System reviews notification log and redacts all sensitive data (only last 4 digits in any support UI/conversation). 5. Bank staff updates contact details, logs change (check masking in audit log). 6. Re-send due notification to corrected contact, verify content formatting and card masking again. 7. Misdelivered notification is marked for audit review, verify PII policy is followed. 8. Simulate a follow-up overdue alert; confirm it goes only to right contact, with masking and no repeat error. 9. Review logs, user communication, error responses for full compliance throughout.", + "expectedResult": "Notification misdelivery does not reveal full card number or additional PII; all notifications and error/support content show last 4 digits only; audit logs reflect correction actions and masking; end-user and staff UI are compliant; issue resolved without exposure of sensitive data.", + "channelsTested": "Email, SMS, Support Portal", + "piiFieldsValidated": "Last 4 digits of card, contact information redacted", + "rolesInvolved": "Customer, Incorrect Contact, Bank Staff, Support Agent", + "regulatoryChecks": "PCI DSS, GDPR, bank-specific PII incident handling" + }, + { + "type": "Payment Plan Boundary & Eligibility", + "title": "Payment Plan Generation for Boundary Amounts and Ineligible Accounts", + "description": "Covers generating payment plan proposals for overdue balances at zero, below threshold, exceedingly large, and confirms system rejects or adapts appropriately based on business rules and eligibility logic.", + "testId": "ZBIO-5213-PP-BOUNDARY-07", + "testDescription": "Verifies payment plan proposal logic, end-user communication, rejection handling, regulatory-mandated content, and consistent masking for eligible and ineligible scenarios at boundary values.", + "prerequisites": "Credit card accounts set up with overdue balances: 0, $49 (below minimum plan threshold), $500 (threshold), $100000 (max), system-configured payment plan eligibility criteria, collection workflow enabled.", + "stepsToPerform": "1. Simulate due account with $0 balance, attempt to trigger payment plan proposal; observe system behavior and communication. 2. Repeat for account below minimum threshold, attempt plan generation, and review resulting notification for content and masking. 3. For threshold and max balance, generate plan proposal, deliver via email/SMS/UI; confirm schedules, interest/fee structure, and proper masking of card digits. 4. Attempt acceptance and rejection of offered plan as user, observe system and notification updates. 5. For rejected/ineligible cases, inspect logs and notifications for regulatory content and no PII exposure. 6. Test repeat proposal for same account within lockout/cooldown window; system should block or warn. 7. Simulate user dispute on plan eligibility, trigger review/decision; ensure proper redaction in all outputs. 8. Review all communications and downloadable documents for unique account cases. 9. Audit log all attempts, responses, and system decisions—validate masking throughout.", + "expectedResult": "Payment plan proposals only generated for eligible/valid accounts and balances; all communication strictly masked for card digits; ineligible cases handled by business rules, regulatory-compliant responses shown; audit trail reflects all attempts with required redactions.", + "boundaryValuesCovered": "0, below threshold, threshold, maximum", + "channelsTested": "Email, SMS, UI, Downloadable Docs", + "rolesInvolved": "Customer, Bank Staff" + }, + { + "type": "Integration & Regulatory Failure Handling", + "title": "Collection Agency Handoff Failure with Masked Notification and Retention Validation", + "description": "Tests how system handles failed collection agency integration/handoff, ensures all communication and stored logs use only masked card numbers, and regulatory retention schedules are enforced.", + "testId": "ZBIO-5213-AGENCY-FAIL-08", + "testDescription": "Simulates agency system outage or rejection, audits communications/logs for compliance, retried handoff, and checks proper masking on failover, error, and all retry interactions.", + "prerequisites": "Account in overdue/collection state eligible for agency handoff, collection agency integration set to fail (down/unavailable), system log and retry mechanism enabled, regulatory policy configured.", + "stepsToPerform": "1. Progress overdue account to collection/escalation state eligible for agency handoff. 2. Trigger agency handoff, simulate external system returns error/unavailable. 3. System logs all handoff attempts and failures, generates customer/staff notification (masked). 4. Verify notification content for customer, agency, and staff—must display only last 4 digits. 5. Attempt auto-retry after defined interval, simulate continued failure, check escalation path. 6. Bank staff initiates manual handoff, review resulting communications and logs for compliance/masking. 7. As integration recovers, system completes handoff, logs all transitions with masking in all output. 8. Confirm all handoff, error, notification, and retry logs are retained in regulatory-mandated audit storage. 9. Download all handoff records and verify content formatting, absence of PII beyond allowed masked digits.", + "expectedResult": "Failed agency handoff triggers appropriate error/notification with strict card masking; no full card number exposed at any point; automated/manual retries handled cleanly; all audit records and notifications remain compliant and are stored per retention policy.", + "integrationPoints": "Collection Agency System, Audit Log, Notification Engine", + "rolesInvolved": "Bank Staff, Collection Agent, Customer", + "regulatoryChecks": "PCI DSS, Audit Retention, Redaction" + }, + { + "type": "Legal Escalation and Document Validation", + "title": "Legal Action Initiation With Notification, Document Generation, and Masking Validation", + "description": "Ensures legal escalation triggers, documentation, notifications, and content are strictly masked, formatted per regulatory/legal requirements, and subject to retention rules with audit trail.", + "testId": "ZBIO-5213-LEGAL-09", + "testDescription": "Exercises all legal action workflows, checks for masking of the last 4 digits in notices, legal docs, and UI, audits legal handler actions, retention periods, and protection against accidental/unapproved access.", + "prerequisites": "Active account in delinquent/default state, legal handler role provisioned, document generation templates with masking, regulatory retention policy loaded, multiple notification channels in place.", + "stepsToPerform": "1. Progress account through due, overdue, collection, and external/agency to legal-eligible state. 2. Legal handler initiates legal action in system; documents (notices, filings) are generated. 3. Review all legal document content (header, body, footer, annex) for masking/card number format. 4. Generate legal notification for customer (email, SMS, physical letter), verify only last 4 digits display. 5. Attempt access of generated/legal documents by various roles (customer, bank staff, unauthorized user, agency); system must enforce masking and restrict access. 6. Review audit trail of all access, document generation, modification, and notification actions. 7. Confirm regulatory formatting and mandatory legal content are present in all channels. 8. Examine document download/storage—validate retention per regulatory/policy timelines. 9. Simulate legal closure or recovery pre-judgment; confirm corollary notifications and documents maintain required masking.", + "expectedResult": "All legal docs/notices/communications display only last 4 digits of credit card; templates and UI enforce redaction at all points; access control restricts processing and viewing; audit trail, retention, and regulatory formatting validated.", + "documentTypesTested": "Legal Notice, Court Filing, Recovery Notice", + "rolesInvolved": "Legal Handler, Customer, Bank Staff, Unauthorized User, Collection Agent", + "regulatoryChecks": "PCI DSS, Court/Legal Formatting, Access Control, Retention" + }, + { + "type": "Data Validation & Negative UI Scenario", + "title": "Invalid User Input and Overdue Calculation Error Handling With Secure Messaging", + "description": "Covers UI entry of invalid payment amounts (negative, zero, overlimit), tests overdue/fee miscalculation correction, and ensures all messages (including errors) are masked and compliant.", + "testId": "ZBIO-5213-DATA-VAL-10", + "testDescription": "Traces data validation for all monetary fields, in-app error message flow, recalculation after correction, and validates no comm or UI error exposes full card or extra PII.", + "prerequisites": "Overdue account for web portal access, monetary validation logic implemented, staff override staff, typical error triggers set, notification system enabled.", + "stepsToPerform": "1. Cardholder logs into portal, attempts to pay negative value—UI prevents, displays error (masked). 2. User enters zero payment; system blocks/alerts, checks message content for regulatory/PII compliance. 3. Input above allowed max (e.g., more than balance), triggers error, review message, masking, and notification log. 4. Staff user identifies a system-calculated overdue/fee inconsistency, submits correction/override. 5. User receives updated notification with correct overdue/fee values, card remains masked. 6. Download audit log, review calculation attempts, overrides, action logs—all must show proper masking. 7. Simulate UI/API integration error in payment attempt, verify user and staff error comms for PII/masking. 8. Attempt to download statement after correction; inspect for accurate amounts and proper formatting/masking. 9. Test correct display of boundary values (minimum, threshold, maximum) in UI, notifications, documents.", + "expectedResult": "No invalid payment inputs processed; all error/info messages and notifications display only last 4 digits of card; overdue/fee calculation errors correctable by staff with logs; content and outputs are masked and audit ready.", + "boundaryValues": "Negative, zero, minimum, usual, maximum", + "rolesInvolved": "Customer, Bank Staff, System Admin", + "channelsTested": "UI, Email, Download, Notification Log", + "regulatoryChecks": "PCI DSS, Communication Masking, Monetary Calculation Accuracy" + }, + { + "type": "Notification Suppression and Out-of-Cycle Payment", + "title": "Notification Suppression Upon Early Payment with State Transition Verification", + "description": "Ensures when a cardholder makes an early payment before the scheduled due reminder, the system halts or retracts scheduled notifications, updates workflow state, verifies that no overdue or collection notices are sent, and validates that masking of card digits is consistent throughout.", + "testId": "ZBIO-5213-SUPP-11", + "testDescription": "Verifies system behavior and notifications upon early/full payment prior to due date, checking for correct state rollback, audit log record, notification suppression, masking enforcement, and proper communication on state and PII compliance.", + "prerequisites": "Customer with open card account, future scheduled due, due reminder workflow active, payment/transaction feature enabled. Notification engine and audit trail active.", + "stepsToPerform": "1. Cardholder logs into portal and views upcoming due reminder scheduled for card ending 4321. 2. Cardholder makes full payment before reminder date. 3. System auto-updates account status to 'current', cancels all scheduled due/overdue notifications for this cycle. 4. Attempt to trigger overdue/collection reminder as system; operation should be suppressed. 5. System auto-generates a receipt notification with only last 4 digits, confirming payment and status. 6. Cardholder and staff confirm no overdue/collection communication is generated for account. 7. Review portal, mobile, and email for any notifications—confirm only masking, no extra PII appears. 8. Download audit log showing suppressed notification attempts and payment action, validate masking in log. 9. Attempt state reversal (apply transaction reversal); check workflow and messaging for correct masking.", + "expectedResult": "No overdue/collection notices sent after early payment, all system communications including suppression logs use only last 4 digits of card, state remains 'current', and all steps/audits comply with masking and regulatory rules.", + "workflowsCovered": "Due Reminder, Overdue Alert, State Transition, Notification Suppression", + "rolesInvolved": "Customer, Bank Staff, System", + "channelsTested": "UI, Email, Mobile App, Audit Log", + "regulatoryChecks": "PCI DSS Masking, Notification Suppression Policy, Record Retention" + }, + { + "type": "Escalation Override and Manual Intervention", + "title": "Manual Override of Collection Escalation and Audit Compliance", + "description": "Covers scenario where bank staff overrides or halts an automated escalation to collections due to special customer circumstances, requiring manual approval and regulatory-compliant logging and masking.", + "testId": "ZBIO-5213-MAN-12", + "testDescription": "Confirms that escalation overrides are effective, automated collections are paused/stopped, documentation and communications reflect masking and proper status, and all user actions and reasons are audit-logged.", + "prerequisites": "Overdue account with standard escalation workflow, bank staff role with override permissions, audit trail system enabled, overdue balance at escalation threshold.", + "stepsToPerform": "1. Progress account to overdue with scheduled escalation. 2. System triggers automated collection escalation workflow. 3. Bank staff logs in, identifies customer as eligible for escalation override/exception based on policy. 4. Staff applies manual hold/override via collections UI; enters justification. 5. System cancels or delays all collection notifications, logs override with masked card digits in both summary and detail fields. 6. Customer receives compliant notification reflecting revised status, only last 4 digits shown. 7. Attempt to trigger external agency handoff—operation should be blocked, with user-facing error that includes only masked digits. 8. Download full audit trail for workflow, validate entry of override action, associated reason, time, and only masked PII. 9. Bank security/compliance user reviews override action for regulatory check.", + "expectedResult": "All escalation overrides are respected, blocked notifications/logs retain masking, staff and customer notifications compliant, regulatory and audit trail requirements are fully met.", + "workflowsCovered": "Overdue Escalation, Collection Hold, Notification Override", + "rolesInvolved": "Bank Staff, Customer, Compliance User", + "channelsTested": "UI, Email, Audit Log", + "regulatoryChecks": "PCI DSS Masking, Override Logging, Regulatory Record Keeping" + }, + { + "type": "Dispute Handling and Time-Bound State Freeze", + "title": "Disputed Overdue Amount and Temporary Suspension of Collections", + "description": "Validates that when a customer disputes an overdue or fee, system suspends all escalations, halts notifications, applies time-bound freeze, and resumes with compliant content and masking post-resolution—tests all system outputs and reversals.", + "testId": "ZBIO-5213-DIS-13", + "testDescription": "Checks state freeze, proper notification handling (suspension, restart, reissue), dispute record creation with only masked digits, and final state updates. Includes negative validation where dispute is rejected or updated.", + "prerequisites": "Cardholder with overdue balance, active overdue/collection workflow, dispute management enabled, staff with dispute resolution access, notification system in place.", + "stepsToPerform": "1. Customer receives overdue notification (only last 4 digits displayed) for card ending 5555. 2. Customer raises dispute on overdue fee via portal. 3. System suspends escalation/collection, with suspension recorded in audit log—masking enforced. 4. No further collection/agency/legal notifications are sent during dispute period. 5. Bank staff reviews and resolves dispute—either approve, adjust, or reject. 6. If dispute resolved with adjustment, customer and staff receive updated notification of new balance (masked digits only). 7. If dispute rejected, overdue workflow resumes, notifications generated with proper content and masking. 8. Attempt to manually trigger agency/legal action while dispute is open, system must block and log with masked digits. 9. Review audit log, confirm all state changes, notifications, dispute actions are tracked and redacted.", + "expectedResult": "Dispute state triggers correct freeze of escalation, all notifications and logs use only last 4 digits, post-resolution actions and messaging are masked and regulatory-compliant.", + "workflowsCovered": "Dispute Handling, Overdue/Collection Escalation, Notification Suppression, State Freeze", + "rolesInvolved": "Customer, Bank Staff, Dispute Handler", + "channelsTested": "UI, Email, Audit Log", + "regulatoryChecks": "PCI DSS, Dispute Regulatory Requirements, Masking" + }, + { + "type": "Multiple Cardholder Accounts and Cross-Product Masking", + "title": "Parallel Due and Collection Workflows for Multiple Cards Held by Same User", + "description": "Ensures system cleanly manages and displays concurrent workflows for users with multiple credit cards, validating masking, notification segregation, cross-notification errors, and correct state/fee treatment for each card individually.", + "testId": "ZBIO-5213-MULTI-14", + "testDescription": "Each account/card flows through due, overdue, collection, and possible legal handoff, with separate masking, logs, and resolution; system must not mix digits/data between cards in any notification or log, even in error", + "prerequisites": "Cardholder user with two or more active credit cards, separate balances and due dates, workflows and notification system active, test with cards ending 1010 and 2020.", + "stepsToPerform": "1. Set up two cards: one enters due reminder and early payment, another progresses through overdue, collection, and agency handoff. 2. System sends notifications for each card individually (email, SMS, portal), each reflecting correct last 4 digits. 3. Cardholder responds to one notification (partial payment), system updates that card only. 4. Progress second card to agency/legal state, trigger all notifications and docs—confirm segregation and masking. 5. Inject simulated system error causing cross-notification; system must block, correct, and log with exception, masking enforced. 6. Staff/agency attempts bulk notification—system must ensure only correct last 4 digits shown for each card, and audit any batch errors. 7. Download all user and staff notification/audit logs; review for proper content, segregation, and masking per card. 8. Close one workflow, verify remaining notifications/communications for active card continue as expected and masked. 9. Simulate agency/dispute action on one card, review all impacts and masking.", + "expectedResult": "No mixing of notifications or card data; all content (UI, email, logs, docs) displays correct last 4 digits per card; cross-notification errors handled gracefully with full masking, no full card data exposure at any time.", + "workflowsCovered": "Due Reminder, Overdue Alert, Collection Notification, Agency Handoff, Legal Escalation", + "rolesInvolved": "Customer, Bank Staff, Collection Agent", + "channelsTested": "UI, Email, SMS, Download, Audit Log", + "regulatoryChecks": "PCI DSS, Multi-Account Masking, Notification Segregation" + }, + { + "type": "Legal Recovery and Post-Closure Communication", + "title": "Post-Legal Closure State Notification and Regulatory Retention Validation", + "description": "Validates all communication, documentation, and state/log update on post-legal closure or successful recovery, including customer final notification, system archival, and retention enforcement with masking.", + "testId": "ZBIO-5213-POST-15", + "testDescription": "Checks that system issues only masked final/closure notification to all involved roles, blocks future notifications, logs all actions, and archives all documentation as per regulatory schedules.", + "prerequisites": "Delinquent account escalated through legal/judgment state, system with close/recovery action enabled, retention archiving configured, staff and customer users available.", + "stepsToPerform": "1. Complete legal/litigation workflow for card ending 9898, trigger closure (either via recovery or legal judgment). 2. System updates account state to 'closed'/'recovered' and generates closure notification/documentation for all parties (masked digits only). 3. System disables future notifications/workflows. 4. Customer receives closure confirmation via all channels (email, SMS, portal notification), review masking. 5. Legal/collections handler receives closure/completion notice, only last 4 digits shown on all content. 6. Attempt to trigger any further escalation/agency/legal action—should be blocked and properly logged. 7. Audit/download all final actions, notifications, and closure records—check for masking compliance. 8. System archives all documentation to regulatory retention system, confirm access is masked and restricted. 9. Conduct compliance check on archived records after closure for accessibility and masking.", + "expectedResult": "All post-closure communications use only the last 4 digits, no leakage of card or personal data, system disables further actions, audit trails and records are masked and archived per compliance standards.", + "workflowsCovered": "Legal Closure, Notification, Archive/Retention, State Transition", + "rolesInvolved": "Customer, Legal Handler, Collection Agent, Bank Staff", + "channelsTested": "UI, Email, SMS, Download, Archive System", + "regulatoryChecks": "PCI DSS, Retention Policy, Masking, Access" + }, + { + "type": "UI Workflow & Masking Validation", + "title": "Portal UI and Document Download Masking End-to-End For All Collection States", + "description": "Covers the journey of a single overdue account through all UI states including downloadable documents, ensuring the last 4 digits of the card are displayed but never the full card number, even in deep links, download names, and generated statements.", + "testId": "ZBIO-5213-UI-MASK-16", + "testDescription": "Validates UI rendering and downloadable content for due/overdue/collection/legal states. Confirms masking remains enforced on all screens, in browser titles, download names, popups, and embedded PDF or statement files. Negative case includes previewing system temp files and erroneous downloads.", + "prerequisites": "Active cardholder account with overdue amount, access to portal, due reminder and escalations pending. Collection workflow and document generator enabled. Multiple statements/downloads available.", + "stepsToPerform": "1. Login as cardholder and open dashboard; verify due reminder notification in UI for card ending 1111. 2. Navigate to documents section, download due reminder PDF/statement—inspect content and file name for card masking. 3. Simulate payment miss; dashboard updates to overdue alert—review alert UI, embedded amount and masked digits. 4. Open notifications and download overdue notice—inspect masking in content, bug report if digits appear outside policy. 5. Allow account to escalate to collections—review collection notice in UI, download associated doc, verify masking. 6. Simulate legal escalation; access and download all generated legal documents (letters, notices), check content and header/footer for PII/masking. 7. Attempt to access system logs/downloads as unauthorized user—system blocks view and redacts all digits. 8. Try deep-linking into download or accessing previous download via browser history; verify response is masked and access blocked if role unauthorized. 9. Review and audit UI, notifications, downloads and browser artifacts for consistent masking in all UI and backend output.", + "expectedResult": "In all UI views, doc downloads, and notification areas, only the last 4 digits of the card are displayed or written into content, names, and logs; all unauthorized or backend artifact access is blocked/redacted; no scenario exposes full card number anywhere.", + "workflowsCovered": "Due Reminder, Overdue Alert, Collection Escalation, Legal Action, Document Generation", + "channelsTested": "Portal UI, PDF Download, Notification Center, Document Archive", + "rolesInvolved": "Customer, Bank Staff, Unauthorized User", + "regulatoryChecks": "PCI DSS, GDPR, Bank Policy Masking", + "piiFieldsValidated": "Last 4 digits only, all comms and downloads" + }, + { + "type": "Audit Log and Retention Enforcement", + "title": "Comprehensive Audit Trail and Record Retention After Payment, Escalation and Legal Handoff", + "description": "Ensures that all actions from overdue reminder through payment, escalation, agency/ legal handoff, and closure are logged with required detail, proper masking, and are available or purged in line with regulatory/retention policy.", + "testId": "ZBIO-5213-AUD-17", + "testDescription": "Trace each state/action, verify the audit trail contains correct actor/timestamp, status, masked card digits, and no extra PII—even on exceptional paths (manual update, agency handoff retry, legal close). Ensure records remain available strictly per retention rule and are deleted or made inaccessible after retention window.", + "prerequisites": "Cardholder account in overdue, existing audit log system and regulatory retention policy enforced, agency/legal handler access. System time control for retention testing.", + "stepsToPerform": "1. Cause overdue event for card ending 2222; confirm overdue and notification are logged (audit record, last 4 digits only). 2. Cardholder pays partially, audit records update—check masking and details. 3. Miss a second payment, trigger collection escalation; verify agency handoff is logged with mask and required info only. 4. Manually escalate to legal; legal handler action and document generation are separately logged. 5. Legal handler closes case, triggers recovery or permanent closure—action and reason logged and masked. 6. Fast-forward system clock to post-retention threshold; attempt to access/download old audit log as staff/admin—access should be denied or redacted beyond retention. 7. Attempt to retrieve older escalation or legal logs as agency/legal user; audit denies access/removes after regulatory period. 8. For all audit exports (CSV, JSON), check output for masking and lack of full PII. 9. Review portal/audit UI for log detail, retention, and regulatory formatting.", + "expectedResult": "All state transitions, payments, escalations, and closures are properly logged, each with actor, time, action, and only masked card number; no full card or unmasked data ever present; records become irretrievable or purged as per policy; audit downloads extract only last 4 digits where required.", + "workflowsCovered": "Overdue, Payment, Collection Escalation, Agency Handoff, Legal Close, Retention", + "rolesInvolved": "Bank Staff, Legal Handler, Collection Agent, Admin", + "channelsTested": "Audit Log UI, Download, Admin Tools", + "regulatoryChecks": "PCI DSS, Retention Policy, Audit Requirements", + "piiFieldsValidated": "Masked digits only in audit and export" + }, + { + "type": "Fee and Penalty Calculation Accuracy", + "title": "Penalty, Fee, and Interest Assessment at All State Transitions with Negative/Boundary Values", + "description": "Tests fee and penalty calculations for all balance states (zero, negative, threshold, max), especially at the moment of state transition (current to overdue, overdue to collection/legal), and checks all notification and log outputs for masking and accuracy.", + "testId": "ZBIO-5213-FEE-18", + "testDescription": "At each due-to-overdue-to-collection-baseline transition, validate overdue fee/interest calculation, fee waivers/discounts, rounding/edge cases, and notification content. Negative test for negative/zero/over-max values in every state. Masking of all outputs checked.", + "prerequisites": "Multiple accounts with due balances at 0, negative, threshold, max limit, system with automated fee/penalty logic enabled and override permissions for staff.", + "stepsToPerform": "1. Account due with zero balance—trigger state change to overdue; verify no penalty assessed, notification correct and masked. 2. Account with negative balance, process overdue—should not assess fee, check notification and masking. 3. Second account hits exact threshold for late fee assessment, trigger overdue—fee is applied, validate calculation and comm masking. 4. Account passes to collection state, triggers new penalty/interest tier—calculate, verify content and masking. 5. Bank staff applies partial/waiver or adjustment, verify recalculated amount, notification, and audit masking. 6. Account escalates to legal state, max penalty reaches cap—validate legal notification, amount, and redaction. 7. Attempt manual override of fee via UI/API; verify logs, masking, and regulatory note. 8. Simulate erroneous calculation/failure in backend (divide by zero, null)—system should display error, still masked, and log incident. 9. Download and review all comms/logs/statements for affected cases.", + "expectedResult": "Penalties, fees, and interest calculations/communications are mathematically correct, enforced only within allowed boundaries; all notifications and audit records display only masked digits and maintain policy; system blocks/recovers from calculation errors with compliant messaging.", + "boundaryValues": "Zero, negative, exact threshold, maximum supported", + "workflowsCovered": "Overdue, Collection, Legal Escalation, Fee Assessment", + "channelsTested": "Notification, UI, Download, Audit Log, API", + "rolesInvolved": "Bank Staff, System Admin, Customer", + "regulatoryChecks": "PCI DSS, Fee Disclosure Policy, Calculation Rounding/Edge Cases" + }, + { + "type": "Integration Cross-Workflow Error Handling", + "title": "Asynchronous Integration Error and Retry Path for Notification and Handoff Escalation", + "description": "Tests synchronous/asynchronous failures for notification and collection agency/legal handoff systems—including network lag, incomplete status, double-sending, and masks data in both failure and success notification flows and logs.", + "testId": "ZBIO-5213-INTERR-19", + "testDescription": "Simulates notification engine/agency integration delay/outage; system must retry, provide interim notifications, mask all card digits correctly, and log all events. Also covers double-execution errors and message de-duplication.", + "prerequisites": "Overdue/collection account, integration to notification and external agency system toggled for random delay/failure configuration. Audit log enabled, multiple endpoint channels enabled.", + "stepsToPerform": "1. Progress account to overdue, trigger first notification—simulate notification server delay. 2. System retries notification after timeout, leaves interim log and customer notification (masked). 3. Escalate to collection; trigger agency handoff with network error, system must queue and retry, log masked handoff attempts. 4. On retry, ensure no duplicate notifications sent (system suppresses repeats, logs each attempt/masking). 5. During delay, bank staff attempts to manually resend/cancel; all attempts are logged, notifications use only masked digits. 6. On integration restore, verify handoff/completion comm is sent correctly to all parties with masking. 7. Simulate customer request to review notification history during period; only one masked notification visible each step, no confusion or duplicates. 8. Trigger legal escalation with similar delay—ensure all legal docs, notices, and audit items reflect proper sequence and masking, without duplication or skipped steps. 9. Download and review integration retry/incident logs for proper formatting.", + "expectedResult": "System handles delays/failures gracefully, does not double send, each notification/log shows only last 4 digits, and all audit/integration retry history is masked and compliant; no full card number leaks, event flow is traceable and deduped.", + "workflowsCovered": "Notification, Agency Handoff, Legal Escalation, Integration Retry", + "channelsTested": "Email, SMS, UI, API, Audit Log", + "rolesInvolved": "Customer, Bank Staff, Collection Agent, Legal Handler, System Admin", + "regulatoryChecks": "PCI DSS, Resilience Policy, Notification De-duplication, Masking On Failure" + }, + { + "type": "Payment Plan Acceptance and Payment Reversal Handling", + "title": "Partial Payment Against Plan With Subsequent Payment Reversal and State Recovery", + "description": "Explores initiation of payment plan, partial completion, reversal of payment, and how system recovers state—evaluating all user/staff notifications and masking at each event.", + "testId": "ZBIO-5213-PLAN-RV-20", + "testDescription": "Covers offering a payment plan, partial user payments, triggered reversal (manual or dispute), correct update of account/plan status, and masking of all notifications/logs on each path—both positive (recovery) and negative (default/rollback).", + "prerequisites": "Overdue cardholder account, eligible for plan, partial payment/reversal logic configured, staff with reversal/override permissions, audit log active.", + "stepsToPerform": "1. Customer receives overdue notification, given payment plan for card ending 3333 (masked digits). 2. Plan accepted, customer makes initial partial payment, system updates plan and logs with masking. 3. Customer attempts to reverse/stop latest payment (via dispute or support); triggers reversal path. 4. System cancels/re-applies payment, updates status, sends notification to customer and staff (masked last 4 digits). 5. Plan status reverts to pre-payment, overdue/collection comm is triggered (masked). 6. Staff reviews audit records for payment and reversal—all fields masked. 7. Customer tries again; overpays partway through plan, checks notification generated for excess, masking confirmed. 8. System provides new plan schedule, updates and notifies involved roles (masked). 9. Download audit and comm log of all plan/reversal/recovery steps—review for sequence, content, and masking.", + "expectedResult": "All actions across payment plan, partial/reversal/overpayment, and status update remain fully masked (last 4 digits only) in every notification, comm, UI, and log; state transitions are correctly reflected; audit meets legal/regulatory requirements.", + "workflowsCovered": "Payment Plan, Partial Payment, Payment Reversal, State Management", + "channelsTested": "UI, Email, SMS, Audit Log, Support Case", + "rolesInvolved": "Customer, Bank Staff, Dispute Handler, System", + "regulatoryChecks": "PCI DSS, State Integrity, Masking Enforcement, Payment Recovery" + }, + { + "type": "Collection Notification Scheduling", + "title": "Multiple Sequential Overdue Notices Prior to Collection Escalation", + "description": "Validates that the system sends a predefined sequence of overdue notifications before triggering the collection escalation, each properly masked, and that suppression logic applies if payment is made mid-sequence.", + "testId": "ZBIO-5213-SCHED-21", + "testDescription": "Ensures the system delivers a sequence of overdue alerts (e.g., first, second, final notice) with increasing urgency, all showing only last 4 digits of card. If payment is made after any notice, escalation stops, logs and residual notifications adhere to masking and regulatory policy.", + "prerequisites": "Cardholder account enters overdue state, sequential notification schedule configured (e.g., T+1, T+5, T+10 days overdue), payment system enabled. Audit log and notification engine active.", + "stepsToPerform": "1. Allow due date to pass without payment for card ending 5678. 2. On Day 1 overdue, system sends first overdue notification via all channels—check masking. 3. On Day 5 overdue, system sends second alert—masking and communication urgency reviewed. 4. On Day 10, system sends final pre-escalation notice—format and masking validated. 5. Cardholder makes partial payment after second notice—system records and recalculates balance, triggers follow-up alert (masked). 6. Cardholder pays in full after third notice—system updates state, suppresses collection escalation. 7. Attempt to trigger manual escalation or notification; verify system suppression and audit masking. 8. Download notification and suppression logs, confirm chronology, masking, and rule compliance. 9. Review portal/state for residual notifications—none should contain full card digits or out-of-sequence alerts.", + "expectedResult": "Each scheduled overdue notice is delivered on time, only last 4 digits of card shown; escalation stops if resolved; all notification, suppression, and audit logs show proper masking; no late/invalid communication is sent.", + "workflowsCovered": "Overdue Alert, Collection Notification, Notification Scheduling, Suppression", + "rolesInvolved": "Customer, Bank Staff, System", + "channelsTested": "Email, SMS, UI, Notification Log", + "regulatoryChecks": "PCI DSS Masking, Notification Sequence Policy, Suppression Rules" + }, + { + "type": "Notification Content and Language Validation", + "title": "Localization and Regulatory Formatting for Multilingual Notifications with Masked Data", + "description": "Validates notification content for language localization, regional regulatory requirements, and consistent card masking, ensuring the correct inclusion of the last 4 digits and compliant formatting across different locales.", + "testId": "ZBIO-5213-LOC-22", + "testDescription": "Tests generation and delivery of due/overdue/collection/legal notifications in multiple languages, enforces masking and regulatory content per regional settings, and confirms formatting integrity for each locale.", + "prerequisites": "Cardholder accounts set with locale preferences (English, Spanish, French, German), notification templates in each language, regulatory text and footers as per locale, integration with notification engine enabled.", + "stepsToPerform": "1. Create overdue event for card ending 2468 assigned to a Spanish-language locale. 2. System generates and sends overdue alert in Spanish, review content, regulatory statement, and masking. 3. Trigger collection notification—validate German template for a different user/location, check masking. 4. Advance account to legal escalation, send legal notice in French, validate body, footers, and masked digits. 5. Simulate user locale change on profile, regenerate due reminder, confirm language switch and content masking. 6. Attempt delivery to unsupported locale—system falls back to default, logs event; content and masking rules validated. 7. Download all notifications and confirm regulatory phrases, footers, and masking accuracy across languages. 8. Inspect any errors/warnings for locale/template mapping—data masking must persist in logs and error content. 9. Attempt manual notification preview as staff for each locale, verify content/masking in UI panels.", + "expectedResult": "All notifications (across states, channels, locales) display only last 4 digits, are formatted per regulatory requirement, deliver the correct language, and enforce masking in all logs and content—even during fallback or errors.", + "workflowsCovered": "Due Reminder, Overdue Alert, Collection Notice, Legal Escalation, Localization", + "channelsTested": "Email, SMS, Portal UI, Download, Templates", + "rolesInvolved": "Customer, Bank Staff, System Admin", + "regulatoryChecks": "PCI DSS, Regional Notification Content, Localization, Masking" + }, + { + "type": "Access Control and Role Revocation", + "title": "Dynamic Role Change Handling during Active Collection Workflow", + "description": "Tests workflow and notification/masking compliance when a user's role/permissions are changed (e.g., collection agent or staff access revoked) in the middle of a due or collection lifecycle, including attempts to continue escalation or view data.", + "testId": "ZBIO-5213-RBAC-23", + "testDescription": "Covers the full set of user and system actions around role modification (permission change or revocation), enforcing access and masking in notifications, UI, and audit logs, both before and after role change. Ensures all subsequent actions (legitimate or blocked) still output only masked digits.", + "prerequisites": "Overdue account in escalated workflow stage, assigned bank staff or collection agent, admin account with role management privileges, audit log enabled, notification engine live.", + "stepsToPerform": "1. Collection agent starts with assigned overdue account for card ending 6789. 2. Agent generates and sends collection notice—content and masking checked. 3. Mid-workflow, admin revokes agent's access to collections feature. 4. Agent attempts to send next notification—system blocks action, generates access denied log and user-facing error (masked). 5. Agent tries to download prior notifications/logs; system restricts access, ensures masked card digits only. 6. Admin restores access, agent resumes workflow—generates next escalation, verify masking. 7. Cardholder responds with partial payment; agent/system action logged and masked. 8. End-user and bank staff attempt to view audit trail of all role changes and related actions; only authorized data and masked digits are visible. 9. Attempt illegal escalation by former agent after demotion, system must log/block with masking.", + "expectedResult": "Role revocation/addition dynamically restricts or allows action; all notifications, UI outputs, and logs during and after the change display only last 4 digits of card; unauthorized actions are blocked and logged; data masking and regulatory requirements always enforced.", + "rolesInvolved": "Collection Agent, Bank Staff, Admin, Customer", + "channelsTested": "Portal UI, Email, Audit Log, API", + "workflowsCovered": "Collection Notification, Role Management, Access Control, Notification Masking", + "regulatoryChecks": "PCI DSS, GDPR, Role-Based Access, Masking" + }, + { + "type": "Fee Recalculation and Retroactive Charge Adjustment", + "title": "Retroactive Policy Change and Fee Recalculation in Active Overdue Case", + "description": "Tests the system's recalculation of fees/penalties and update of all historical and future notifications when a regulatory policy or product-level fee is changed for an active overdue/collection account.", + "testId": "ZBIO-5213-RETRO-24", + "testDescription": "Covers system-initiated recalculation of fees and update/retraction of past and future notification content/logs. Checks that all regenerated, revoked, and adjusted communications continue to show only the last 4 digits; negative case for reverted policy.", + "prerequisites": "Overdue account in escalation with original fee/penalty structure, retroactive policy/fee update scheduled/applied, access to notification/history logs, staff/admin access, notification templates enabled.", + "stepsToPerform": "1. Card ending 4444 becomes overdue and assessed $25 late fee; overdue alert sent (masked). 2. Collection notification includes initial fee—review masking. 3. Regulatory change retroactively reduces late fee to $10 for affected accounts (including in-flight ones). 4. System initiates fee recalculation for active cases, logs event. 5. Generates and sends updated notification to customer and staff, explaining adjusted fee (masked digits only). 6. All prior notifications and audit logs referencing original fee are annotated/updated for compliance—masking validated. 7. Customer queries both new and historical communications via portal; only masked digits shown. 8. Simulate system error during recalculation—outputs and logs must omit full card data and provide regulatory-compliant error. 9. Eventually revert policy; system restores original calculations and logs corrective comm (masked).", + "expectedResult": "Retroactive fee changes propagate to all affected active cases, notifications, and logs; all comms reflect correct fee and show only last 4 digits of card; masking/formatting is enforced throughout recalculation, update, and any errors.", + "rolesInvolved": "Customer, Bank Staff, System Admin", + "channelsTested": "Email, Portal UI, Download, Audit Log, Notification Engine", + "workflowsCovered": "Overdue Alert, Collection Notification, Policy Update, Fee Calculation, Communication Update", + "regulatoryChecks": "PCI DSS, Regulatory Change Policy, Fee Disclosure, Masking" + }, + { + "type": "External System Integration and Notification Consistency", + "title": "Third-Party Notification Broker Integration Consistency and Masking Validation", + "description": "Validates that integration with a third-party notification broker/platform (e.g., Twilio, SendGrid) does not lead to unmasked card data exposure in payloads, logs, or notifications, and ensures all displays/output remain compliant regardless of provider or network path.", + "testId": "ZBIO-5213-EXTINT-25", + "testDescription": "Checks all message payloads, webhook callbacks, and integration diagnostic logs for notification delivery/receipt, confirming only the last 4 digits of card are ever transmitted/shown—never the full card number or extra PII—across all supported brokers.", + "prerequisites": "Active overdue/collection accounts, notification system integrated with at least two third-party brokers (Twilio for SMS, SendGrid for email), webhook endpoints registered, message tracking/audit log active, test/diagnostic mode enabled.", + "stepsToPerform": "1. Account with card ending 1212 enters overdue; system generates notification, routed through Twilio for SMS—capture sent payload and check for masking. 2. Repeat with SendGrid for email—validate card digit masking in both captured payload and user-facing email. 3. Review API webhook callbacks/status notifications for delivery—ensure only masked digits appear in all metadata/logs. 4. Simulate notification transmission failure; inspect error diagnostic, broker logs, and all system outputs—no unmasked data allowed. 5. Resend missed notification, verify payload and logs for masking/consistency. 6. Download and review notification transaction log for each broker; masking, redaction, and audit compliance checked. 7. Switch broker (e.g., platform-initiated or via admin API), trigger overdue/collection/legal notification—review all payload/content for last 4 digits only. 8. Attempt integration in parallel for both brokers—ensure masking holds and no duplication/unmasked artifact appears. 9. Customer retrieves notification history in portal; all messages (original, fail, retry) display only masked card IDs, no full numbers.", + "expectedResult": "No notification payload, log, or output in any broker/platform ever exposes more than last 4 digits; all third-party transmissions, failures, and retries masked; audit/log review across routes and providers confirms policy adherence.", + "rolesInvolved": "Customer, Bank Staff, System Admin, Third-Party Broker", + "channelsTested": "Twilio (SMS), SendGrid (Email), Webhook/API, Portal UI, Audit Log", + "workflowsCovered": "Due Reminder, Overdue Alert, Collection Notification, Legal Notification, Third-Party Integration", + "regulatoryChecks": "PCI DSS, Third-Party Data Transmission Policy, Masking" + }, + { + "type": "Time-Based Escalation & Delayed Payment Handling", + "title": "Delayed Payment After Collection Notification Before Agency Handoff", + "description": "Ensures system correctly handles a delayed customer payment occurring after a collection notification but before external agency handoff, validating notification suppression, masking, audit update, and state transition rollback.", + "testId": "ZBIO-5213-TIME-26", + "testDescription": "Simulates a customer making a full or partial payment after a collection notice but before escalation to agency, confirming suppression of further escalation, proper notification flow, masking in comms/logs, and accurate recovery state outcome.", + "prerequisites": "Account escalated to collection status, pending agency handoff, overdue balance populated, payment/collections integration live, notification audit log enabled.", + "stepsToPerform": "1. Allow account to transition through due and overdue, triggering collection notification (masked last 4 digits). 2. Confirm system schedules escalation to agency in T+3 days if no action. 3. Customer makes full payment two days after collection notice. 4. System receives payment, updates account to 'recovery' or 'current' state, logs event. 5. System auto-suppresses agency handoff, ensures only final confirmation/receipt is sent (masked). 6. Attempts to send agency handoff fail and are blocked by current state. 7. Download notification and audit logs for collection, payment, suppression—validate correct masking. 8. Staff/agent tries to manually escalate; system enforces block and logs event. 9. Portal notifications, statements, and downloadable docs reflect updated state and masking only.", + "expectedResult": "No agency escalation occurs after payment, all communications/logs reflect state change and mask card digits, suppression and rollback rules enforced, no further collection/agency/legal notices generated, notifications remain compliant.", + "workflowsCovered": "Collection Notification, Payment Handling, Agency Handoff Suppression, State Transition", + "channelsTested": "UI, Email, SMS, Audit Log", + "rolesInvolved": "Customer, Bank Staff, Collection Agent", + "regulatoryChecks": "PCI DSS Masking, Notification Suppression, State Consistency" + }, + { + "type": "Notification Template Management & Preview Error Case", + "title": "Bank Staff Edits Notification Templates and Tests Masking in Previews", + "description": "Covers template customization for due/overdue/collection/legal communications, validation of data masking in live preview, and handling of template errors or unrendered fields.", + "testId": "ZBIO-5213-TEMPLATE-27", + "testDescription": "Ensures only masked card digits appear in notification templates/preview, even when fields are edited or default values missing. Negative test for template logic error and audit log review.", + "prerequisites": "Bank staff with notification manager role, UI for editing templates, overdue and legal notification templates available in all formats, preview/audit log system active.", + "stepsToPerform": "1. Bank staff logs into template management UI and selects overdue alert template. 2. Edits message body, inserts card number token—system enforces masking on token placement. 3. Uses preview function to generate sample output for card ending 8888, inspects rendered notification for correct masking. 4. Removes or corrupts token to simulate error; preview to user shows error message. 5. System auto-fallbacks to default template/field, ensures masked digits or placeholder. 6. Save and publish template; trigger sample notification delivery (email/SMS). 7. Retrieve sent notifications—examine masking, formatting, and regulatory disclaimer. 8. Inspect error logs and audit trail for template event, verify masking/redaction in error details. 9. Attempt to revert to previous template—ensure old versions never had unmasked digits when reviewed in preview/log.", + "expectedResult": "Templates/previews always render only last 4 digits, never full card number; template field errors or missing data never expose raw digits in any output or log; all changes and previews are audit-logged with masking.", + "rolesInvolved": "Bank Staff, System Admin", + "channelsTested": "UI, Email, SMS, Notification Preview, Audit Log", + "workflowsCovered": "Notification Content Management, Regulatory Masking", + "regulatoryChecks": "PCI DSS, Template Management Policy, Masking On Preview" + }, + { + "type": "Cross-Product Payment & Collection Impact", + "title": "Linked Product Payment (Loan Repayments, Credit Card Due) and Notification Consistency", + "description": "Tests impact on collection notification and state when a customer pays a linked loan or product that affects available credit/overdue balance, ensuring notifications, masking, audit, and workflow are updated and compliant.", + "testId": "ZBIO-5213-XPROD-28", + "testDescription": "Simulates scenario where paying a linked loan/overdraft indirectly affects overdue card balance, requiring state recalculation and suppression/updating of collection notifications with masking.", + "prerequisites": "Linked accounts for same customer (card and loan/overdraft), both with overdue or pending payments, workflow engine supports cross-product payment adjustments, notification audit log enabled.", + "stepsToPerform": "1. Cardholder has overdue card (ending 3579) and linked loan in arrears, system triggers overdue and collection workflow for both. 2. Makes loan payment sufficient to credit back to card, reducing or rectifying overdue balance. 3. System recalculates card overdue state, updates workflow/audit logs. 4. Suppresses pending overdue/collection notifications if card is now current/paid. 5. Sends regulatory-compliant update/confirmation to user for all affected products (shows only last 4 digits for card communications). 6. Download and review all historical comms/statements/audit logs for events before and after payment shift, check for accurate data and masking. 7. Simulate partial resolution so card remains overdue—system modifies subsequent notification and reflects recalculated amounts, only masked card digits shown. 8. Bank staff reviews workflow for cross-product adjustment and accesses logs—masking persists. 9. Attempt next step escalation; system bases triggers on updated state post-cross-product payment.", + "expectedResult": "Workflow accurately reflects cross-product payments; no overdue notices sent in error; all updated/confirmation comms and logs contain only masked digits for card; regulatory compliance maintained throughout.", + "workflowsCovered": "Overdue Alert, Collection Notification, Cross-Product Adjustment, Recalculated Notification", + "channelsTested": "Portal UI, Email, SMS, Download, Audit Log", + "rolesInvolved": "Customer, Bank Staff", + "regulatoryChecks": "PCI DSS, Notification Accuracy, Cross-Product State Management" + }, + { + "type": "Legal Notification Appeal & Reopened Case Handling", + "title": "Legal Case Reopening After Customer Appeal and Masked Communication Validation", + "description": "Covers a previously closed legal case being reopened following a customer appeal, confirming regenerating of legal notifications, masking, and audit logs for all reinstated workflow stages.", + "testId": "ZBIO-5213-APPEAL-29", + "testDescription": "Validates workflow for reopening a legal/closed collection case, communication sent on reopened status/milestones, only last 4 card digits included in all channels, and full masking in logs/statements.", + "prerequisites": "Account previously closed via legal recovery/judgment, customer with right to appeal/reopen, staff/legal handler with reopen function, all notification channels and audit log enabled.", + "stepsToPerform": "1. Case for card ending 7410 is closed after legal state and notification. 2. Customer submits formal appeal/request for review within allowed window. 3. Legal handler reviews, approves reopening—system updates workflow to prior state (collection/legal), logs action. 4. System generates legal reopening notice to customer and staff (masked), per channel. 5. Triggers appropriate notification(s) for current workflow stage (overdue/legal, masked digits only). 6. Customer responds to notice—makes payment or disputes further; system updates accordingly. 7. All audit logs, statements, notification chains for reopened case are reviewed for masking and regulatory text. 8. Closed-status notice is retracted/annotated, new chain shown in portal/audit. 9. Attempt to access/log original closed-case file and new/reopened chain—compare and validate masking, retention, and access.", + "expectedResult": "Reopened legal case triggers only masked notifications, all prior and current audit/communication artifacts reviewed reflect last 4 digits; reopened and closed chains do not expose unmasked digits or raw PII; regulatory and retention policy adhered to.", + "rolesInvolved": "Customer, Legal Handler, Bank Staff", + "workflowsCovered": "Legal Notification, Appeal Workflow, Notification Audit, State Reopen", + "channelsTested": "Email, SMS, Portal UI, Download, Audit Log", + "regulatoryChecks": "PCI DSS Masking, Legal Notification Re-issue, Retention, Appeal Handling" + }, + { + "type": "Consent and Notification Preference Enforcement", + "title": "User Communication Consent Withdrawal and Notification Suppression Validation", + "description": "Validates system compliance when a customer withdraws consent to receive collection/due/overdue communications, enforcing notification suppression, masking in logs, and regulatory fallback messaging.", + "testId": "ZBIO-5213-CONSENT-30", + "testDescription": "Ensures collection, overdue, and legal notifications are suppressed or rerouted as per customer’s withdrawn consent, compensating regulatory mailers sent if required, all outputs masked, and audit logs reflect all consent updates.", + "prerequisites": "Cardholder account with due or overdue state, notification preferences available in profile, consent/withdrawal settings, workflow engine supports suppression, regulatory fallback (postal/mandatory legal notices) enabled, audit log active.", + "stepsToPerform": "1. Customer navigates to notification preferences, withdraws consent for digital communications on card ending 9512. 2. System updates notification preference and audit log (masked last 4 digits in all entries). 3. Due reminder is scheduled—system suppresses all digital notifications as per settings. 4. If regulatory mailing still required, fallback generates physical notice—only last 4 digits shown in content and log. 5. Overdue/collection state transition occurs; system continues to suppress all non-mandatory electronic notices, logs suppression. 6. Attempt to manually send or escalate overdue/collection notification via UI/API—blocked as per consent, log generated (masked). 7. Customer restores consent—future notifications enabled, test new due reminder delivery (masked). 8. All staff/agent access attempts to notification/audit logs are masked. 9. Download history of notification, suppression, fallback, and consent changes—check sequence, access, and that all digests show only last 4 digits.", + "expectedResult": "Customer’s consent preference enforces global suppression of digital comms, fallback notices (if any) fully masked; all notification, suppression, consent update logs accessible only with masked digits per PCI DSS and regulatory requirements.", + "rolesInvolved": "Customer, Bank Staff, Compliance Officer", + "channelsTested": "Portal UI, Email, SMS, Physical Mail, Audit Log", + "workflowsCovered": "Notification Suppression, Consent Update, Regulatory Notice, Communication Preference", + "regulatoryChecks": "PCI DSS, GDPR Consent, Regulatory Notification Fallback, Masking" + } +] \ 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..deabaf1 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..095e9ec --- /dev/null +++ b/functional_tests/ZBIO-5213/ZBIO-5213.yaml @@ -0,0 +1,1051 @@ +openapi: 3.0.3 +info: + title: Credit Card Collection Workflow API + version: 1.1.0 + description: | + API specification for credit card due, collection, masking, notification, compliance, and state management workflows. +servers: + - url: https://api.finorg.example.com + description: Production Base URL + - url: https://sandbox.finorg.example.com + description: Sandbox Environment + +tags: + - name: Collections + - name: Notifications + - name: Auditing + - name: PaymentPlans + - name: Legal + - name: AgencyIntegration + - name: Roles & Access + +security: + - bearerAuth: [] + - apiKey: [] + +components: + securitySchemes: + bearerAuth: + type: http + scheme: bearer + bearerFormat: JWT + apiKey: + type: apiKey + in: header + name: X-API-Key + parameters: + CardLast4: + name: card_last4 + in: path + required: true + description: Last 4 digits of the masked card number + schema: + type: string + pattern: '^\d{4}$' + EntityId: + name: entity_id + in: path + required: true + description: Collection entity unique identifier + schema: + type: string + Channel: + name: channel + in: query + required: false + description: Notification channel (Email, SMS, UI, Download, etc) + schema: + type: string + enum: [SMS, Email, UI, Download] + Locale: + name: locale + in: query + required: false + description: Locale/language setting for notification (English, Spanish, etc) + schema: + type: string + Role: + name: role + in: header + description: User role for access control + schema: + type: string + enum: [Customer, Bank Staff, Collection Agent, Legal Handler, System Admin, Unauthorized User] + IntegrationState: + name: integration_state + in: query + required: false + description: Integration state (up, down, up after retry) + schema: + type: string + enum: [up, down, up after retry] + Broker: + name: broker + in: query + required: false + description: Notification broker (Twilio, SendGrid) + schema: + type: string + enum: [Twilio, SendGrid] + IncorrectContact: + name: incorrect_contact + in: query + required: false + description: Incorrect contact info (for negative test paths) + schema: + type: string + + schemas: + MaskedCard: + type: string + pattern: '^\d{4}$' + description: Last 4 digits of card, fully masked elsewhere + Balance: + type: number + description: Account balance, boundary values validated + Fee: + type: number + description: Fee/penalty calculated + PlanStatus: + type: string + enum: [eligible, ineligible, pending, accepted, rejected] + + CollectionEntity: + type: object + required: + - masked_card + - balance + properties: + entity_id: + type: string + masked_card: + $ref: '#/components/schemas/MaskedCard' + balance: + $ref: '#/components/schemas/Balance' + fee_applied: + $ref: '#/components/schemas/Fee' + state: + type: string + description: Account workflow state + audit: + type: object + description: Audit information + properties: + actor: + type: string + timestamp: + type: string + format: date-time + action: + type: string + masked_card: + $ref: '#/components/schemas/MaskedCard' + Notification: + type: object + required: + - masked_card + - content + - channel + properties: + notification_id: + type: string + masked_card: + $ref: '#/components/schemas/MaskedCard' + content: + type: string + channel: + type: string + status: + type: string + enum: [sent, suppressed, failed, delivered, masked, blocked] + locale: + type: string + + ErrorMasked: + type: object + properties: + code: + type: string + message: + type: string + description: Error description with masking + masked_card: + $ref: '#/components/schemas/MaskedCard' + audit: + $ref: '#/components/schemas/CollectionEntity/properties/audit' + + AuditLog: + type: object + required: + - actor + - action + - masked_card + - timestamp + properties: + log_id: + type: string + actor: + type: string + action: + type: string + masked_card: + $ref: '#/components/schemas/MaskedCard' + timestamp: + type: string + format: date-time + details: + type: string + +paths: + /api/collections/{entity_id}: + get: + tags: [Collections] + summary: Retrieve a collection entity, masked card, and compliance info + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/EntityId' + - $ref: '#/components/parameters/Role' + responses: + '200': + description: Collection entity fetched successfully, masked data only + content: + application/json: + schema: + $ref: '#/components/schemas/CollectionEntity' + '403': + description: Access denied, masked error + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + put: + tags: [Collections] + summary: Update a collection entity, enforcing masking and compliance + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/EntityId' + - $ref: '#/components/parameters/Role' + requestBody: + required: true + content: + application/json: + schema: + $ref: '#/components/schemas/CollectionEntity' + responses: + '200': + description: Entity updated, masked digits confirmed + content: + application/json: + schema: + $ref: '#/components/schemas/CollectionEntity' + '400': + description: Invalid input, masking error response + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + '403': + description: Unauthorized update attempt + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + post: + tags: [Collections] + summary: Create a new collection record, masking enforced + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/EntityId' + - $ref: '#/components/parameters/Role' + requestBody: + required: true + content: + application/json: + schema: + $ref: '#/components/schemas/CollectionEntity' + responses: + '201': + description: Created collection entity, masked digits in response + content: + application/json: + schema: + $ref: '#/components/schemas/CollectionEntity' + '400': + description: Bad input, masked error + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + '403': + description: Unauthorized create attempt + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/state: + get: + tags: [Collections] + summary: Get account state by masked card digits + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Role' + responses: + '200': + description: Account state returned with masking and compliance + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + state: + type: string + balance: + $ref: '#/components/schemas/Balance' + fee_applied: + $ref: '#/components/schemas/Fee' + audit: + $ref: '#/components/schemas/CollectionEntity/properties/audit' + '404': + description: Account not found, masked error + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + patch: + tags: [Collections] + summary: State transition and masked notification/action + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Role' + requestBody: + required: true + content: + application/json: + schema: + type: object + required: + - user_action + - next_state + properties: + user_action: + type: string + next_state: + type: string + justification: + type: string + description: Reason for state change, manual hold, override + responses: + '200': + description: State changed, with masked notification/logs + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + previous_state: + type: string + new_state: + type: string + fee_applied: + $ref: '#/components/schemas/Fee' + notification: + $ref: '#/components/schemas/Notification' + audit: + $ref: '#/components/schemas/CollectionEntity/properties/audit' + '403': + description: Unauthorized action, masked error + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/notifications: + get: + tags: [Notifications] + summary: Retrieve all notifications for masked card + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Channel' + - $ref: '#/components/parameters/Locale' + responses: + '200': + description: Array of masked notifications + content: + application/json: + schema: + type: array + items: + $ref: '#/components/schemas/Notification' + '404': + description: No notifications found, masked error + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + post: + tags: [Notifications] + summary: Trigger notification for masked card + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Channel' + - $ref: '#/components/parameters/Locale' + - $ref: '#/components/parameters/Role' + requestBody: + required: true + content: + application/json: + schema: + type: object + required: [content] + properties: + content: + type: string + scheduled_date: + type: string + format: date-time + responses: + '201': + description: Notification created, masked digits in delivery channel + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '422': + description: Notification suppressed, masking/validation failed + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/audit: + get: + tags: [Auditing] + summary: Fetch audit trail for actions on masked card + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Role' + responses: + '200': + description: Audit log array, only masked digits present + content: + application/json: + schema: + type: array + items: + $ref: '#/components/schemas/AuditLog' + '451': + description: Retention expired/redacted, access denied + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/payment-plan: + get: + tags: [PaymentPlans] + summary: Get payment plan proposal and eligibility for masked card + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + responses: + '200': + description: Returned payment plan eligibility and masked status + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + plan_status: + $ref: '#/components/schemas/PlanStatus' + balance: + $ref: '#/components/schemas/Balance' + notification: + $ref: '#/components/schemas/Notification' + '404': + description: No eligible payment plan, plan suppressed + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + post: + tags: [PaymentPlans] + summary: Accept/reject payment plan for masked card + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Role' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + accept: + type: boolean + amount: + type: number + responses: + '200': + description: Payment plan status updated, masking in logs + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + plan_status: + $ref: '#/components/schemas/PlanStatus' + notification: + $ref: '#/components/schemas/Notification' + audit: + $ref: '#/components/schemas/AuditLog' + '403': + description: Action denied, masked error + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/legal: + post: + tags: [Legal] + summary: Trigger legal action, document generation with masking + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Role' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + action: + type: string + description: Legal action to initiate + responses: + '201': + description: Legal docs created, masked digits and roles enforced + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + documents: + type: array + items: + type: string + notification: + $ref: '#/components/schemas/Notification' + '403': + description: Unauthorized legal action attempt + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/legal/documents: + get: + tags: [Legal] + summary: Fetch legal documents, access control and masking compliance + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Role' + responses: + '200': + description: Legal documents with masked digits + content: + application/json: + schema: + type: array + items: + type: string + '403': + description: Blocked access attempt, masking enforced + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/agency-handoff: + post: + tags: [AgencyIntegration] + summary: Trigger agency handoff, handle failure, masking enforced + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/IntegrationState' + requestBody: + required: false + content: + application/json: + schema: + type: object + properties: + reason: + type: string + description: Reason for handoff/escalation + responses: + '200': + description: Handoff confirmed, masked comms + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + status: + type: string + notification: + $ref: '#/components/schemas/Notification' + '503': + description: Integration failed, masked logs and retry path + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + '403': + description: Unauthorized or blocked handoff + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/fee-calculate: + post: + tags: [Collections] + summary: Calculate fee/penalty, handle overrides and masking + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Role' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + balance: + $ref: '#/components/schemas/Balance' + override: + type: boolean + description: Staff override flag + responses: + '200': + description: Fee calculated or overridden, masking in notifications/logs + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + balance: + $ref: '#/components/schemas/Balance' + fee_applied: + $ref: '#/components/schemas/Fee' + audit: + $ref: '#/components/schemas/AuditLog' + '400': + description: Boundary or invalid balance, error masking + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/notifications/templates: + get: + tags: [Notifications] + summary: Fetch notification templates with masking tokens + security: [bearerAuth: [], apiKey: []] + responses: + '200': + description: Template array, masking tokens validated + content: + application/json: + schema: + type: array + items: + type: object + properties: + template_id: + type: string + content: + type: string + masked_token: + type: string + '403': + description: Access denied, masked error + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + post: + tags: [Notifications] + summary: Create/edit notification template and validate masking + security: [bearerAuth: [], apiKey: []] + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + content: + type: string + masked_token: + type: string + locale: + type: string + responses: + '201': + description: Template created/edited with masking + content: + application/json: + schema: + type: object + properties: + template_id: + type: string + content: + type: string + masked_token: + type: string + '400': + description: Template validation error, masking enforced + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/notifications/broker: + post: + tags: [Notifications] + summary: Route notification via third-party broker, masking ensured + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/Broker' + - $ref: '#/components/parameters/CardLast4' + requestBody: + required: true + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + responses: + '200': + description: Broker notification dispatched, masked digits in payload/logs + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '502': + description: Transmission fails, masked error log and retry path + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/consent: + patch: + tags: [Notifications] + summary: Withdraw or reinstate consent, update audit and masking + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + withdraw: + type: boolean + description: Withdraw consent flag + responses: + '200': + description: Consent updated, comms suppressed or enabled, masking in output/logs + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + notification_status: + type: string + audit: + $ref: '#/components/schemas/AuditLog' + '403': + description: Consent update denied, masking + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/linked-products: + post: + tags: [Collections] + summary: Apply linked product payment, impact collection state, masking in update + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + product_type: + type: string + payment_amount: + type: number + responses: + '200': + description: State recalculated, notifications suppressed and masked + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + state: + type: string + notification: + $ref: '#/components/schemas/Notification' + + /api/accounts/{card_last4}/appeal: + post: + tags: [Legal] + summary: Submit legal case appeal, workflow reopens with masking + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + appeal_reason: + type: string + responses: + '200': + description: Appeal submitted, workflow and masked comms/logs updated + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + state: + type: string + log: + $ref: '#/components/schemas/AuditLog' + + /api/accounts/{card_last4}/dispute: + post: + tags: [Collections] + summary: Raise dispute, freeze escalation and enforce masking + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + reason: + type: string + responses: + '200': + description: Dispute registered, escalation frozen, logs masked + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + state: + type: string + log: + $ref: '#/components/schemas/AuditLog' + + /api/accounts/{card_last4}/dashboard: + get: + tags: [Collections] + summary: Fetch dashboard data, masking on UI documents + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + responses: + '200': + description: Dashboard data, masked digits throughout + content: + application/json: + schema: + type: object + properties: + masked_card: + $ref: '#/components/schemas/MaskedCard' + overview: + type: object + documents: + type: array + items: + type: string + + /api/accounts/{card_last4}/notification-history: + get: + tags: [Notifications] + summary: Retrieve notification history, masked and localized content + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Locale' + responses: + '200': + description: Notification history for account, with masking and localization + content: + application/json: + schema: + type: array + items: + $ref: '#/components/schemas/Notification' + + /api/accounts/{card_last4}/audit-download: + get: + tags: [Auditing] + summary: Export/download audit logs, masking and retention policy applied + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + responses: + '200': + description: Downloadable masked audit log + content: + application/octet-stream: + schema: + type: string + format: binary + '451': + description: Retention expired, access denied or redacted + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/payment: + post: + tags: [Collections] + summary: Process payment, validate masking, error handling + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + amount: + type: number + responses: + '200': + description: Payment processed, masked receipt and logs + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '400': + description: Invalid input (negative/zero/excess), error masking + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/override: + post: + tags: [Collections] + summary: Apply manual escalation hold/override, masking enforced in logs + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + requestBody: + required: true + content: + application/json: + schema: + type: object + properties: + justification: + type: string + responses: + '200': + description: Override applied, masking confirmed + content: + application/json: + schema: + $ref: '#/components/schemas/AuditLog' + '403': + description: Blocked manual handoff, masked error/log + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + /api/accounts/{card_last4}/retry-notification: + post: + tags: [Notifications] + summary: Retry notification/fallback after delivery failure, masking persists + security: [bearerAuth: [], apiKey: []] + parameters: + - $ref: '#/components/parameters/CardLast4' + - $ref: '#/components/parameters/Channel' + responses: + '200': + description: Retry performed, masking ensured in logs/comms + content: + application/json: + schema: + $ref: '#/components/schemas/Notification' + '404': + description: Notification not found or misaddressed + content: + application/json: + schema: + $ref: '#/components/schemas/ErrorMasked' + + # Additional endpoints and parameters can be added for coverage of deep-link UI, downloadable docs, cross-product impact, boundary scenarios, RBAC changes, localization, and regulatory reporting.