7 — Reject & Refund Transfer Upon Death Filing (MVP)

## Problem (WHY)
When a registry analyst rejects a Transfer Upon Death (ToD) filing request, the process must end cleanly: the fee refunded, and the submitting party informed promptly — without creating mail-ins or adding to the scanning backlog.

## Epic Description (WHAT — MVP)
Provide a thin, reliable path so that, once a filing request is **marked Rejected and preserved in Epic 6**, the system:
- Initiates a refund to the original payment method.
- Issues a Rejection Notice (PDF) electronically to the submitting party, with CC to the assigned analyst for confirmation.
- Logs refund and notice events in the audit.

- **Value (who benefits & how):**
- Analysts’ decisions finalize without manual refund/letter work.
- Filers receive timely refund and rejection notice.
- Ops avoid scanning and cheque workflows.
- **Statuses:** Rejected (carried forward from Epic 6).
- **Actions:** Trigger Refund (system); Generate Notice (system).
- **Outcomes:** Refund reference stored; rejection notice generated/sent; filer can download notice; analyst has confirmation.

## Goals (outcomes)
- Process refunds and notices automatically after a Reject decision.
- Make refund and rejection notice clear and timely to the submitting party.
- Ensure a minimal, reliable audit of refund and notice issuance (email sent, CC to analyst, BC Mail job if used).

## Product Personas (in scope)
- **Registry Analyst:** initiates Reject (Epic 6); sees staff-facing outcome of refund/notice; receives CC of email.
- **Filer / Submitting Party (QS):** notified of rejection; can download Rejection Notice.
- **Operations:** benefit from reduced mail-ins and scanning workload.

## Context
- **Where:** Triggered from Filing Request Review page via handoff from Epic 6.
- **Before:** Filing request set to `Rejected` and preserved (Epic 6).
- **After:** Refund reference recorded; Rejection Notice generated/sent; filer can re-download notice; audit shows refund + notification.

## Design Reference Link (Design-owned)
_TBD — Design to paste high-level Figma/overview link before Development estimate._

---

## MoSCoW — MVP scope clarity
- **Must (MVP):**
- Initiate refund to original payment method; store reference/amount; show staff-facing outcome.
- Generate Rejection Notice (PDF) with plain-language reason (mapped from coded reason in Epic 6).
- Send notice electronically (email with link/attachment), with **CC to the assigned analyst**.
- Show immediate **Download** link for the Rejection Notice.
- Store notice ID in audit log; allow filer to re-download from record later.
- Audit log includes refund reference, notice generated, email sent (with CC), and BC Mail job created if used.
- **Should:**
- Show basic staff indicator if refund fails.
- **Could:**
- Allow staff view of refund retry status.
- **Won’t (MVP):**
- Partial/split refunds; cheque processes; retries/chargebacks.
- Branded/multi-language notices.
- Delivery tracking or bounce analytics.
- Resubmission flow (filer must start new request).

---

## Roles & Triggers
- **Registry Analyst (assigned):** clicks Reject in Epic 6 → system triggers refund + rejection notice.
- **System:** Creates refund reference; generates PDF; sends email (with CC); creates BC Mail job; writes audit.
- **Filer:** Receives refund + rejection notice (email, download, mail if required).

---

## Risks & Notes
- **Payment methods:** Refund logic varies across PAD, BC Online, credit card.
- **Policy:** Confirm whether BC Mail fallback is required or if email is sufficient.
- **Privacy:** Ensure filer-only access; staff-only CC.

---

## Dependencies & Systems
- **Epic 6 — Reject Filing Request** (entry condition).
- **Payment service:** Must process refunds; provide reference ID.
- **Notification/Email service:** Send rejection notice, with CC to analyst.
- **BC Mail:** Optional print/mail fallback for notice.

## Dependencies — **BCROS products** (cross-product)
- **BC Online / Accounts:** Refund reference/records. — **Direction:** outbound — **Blocking?: Yes**
- **Notification/Email service:** Send rejection notice, CC analyst. — **Direction:** outbound — **Blocking?: Yes**
- **BC Mail:** Mail fallback for notices. — **Direction:** outbound — **Blocking?: No**

---

## Compliance & Accessibility (guardrails)
- **FOIPPA:** Notices delivered only to filer and CC’d to analyst; no public links.
- **Accessibility:** Keyboard reachable; visible focus; AT announcements for status & document availability.
- **Auditability:** Must record: who rejected, date/time, reason; refund reference/amount; notice ID; delivery methods (email sent + CC, BC Mail job if created).

---

## Post-MVP Candidates
- Delivery retry/tracking (email bounce, refund retry). → Epic 7.P1
- Branded/multi-language templates. → Epic 7.P2

- **Epic Parking Lot (revisit later):**
- Configurable rejection templates.
- Staff view of refund retry status.

- **Epic Exclusions (explicitly not doing):**
- Partial/split refunds; cheque workflows.
- Analytics dashboards.

---

## Linked MVP Stories (IDs and titles)
- **7.2 — Trigger Refund**
- **7.3 — Issue Rejection Notice (PDF + Email + Analyst CC + BC Mail)**

Start at the Filing Request Review page and the Epic 6 Reject Filing Request handoff. Review the payment service, Notification/Email service, BC Mail dependency, and audit requirements before estimating the work. Done means the refund reference and notice are recorded, the PDF is downloadable and emailed with analyst CC, and the required audit events are present.

Written by the indexing model from the issue text.