Financial hardship formal variation workflow

ID	MOD-139
System	SD08
Repo	bank-app
Build status	Not started
Deployed	No

---

Purpose

Implements the statutory hardship variation process that lenders in NZ and AU are required to offer to customers experiencing genuine financial difficulty. When a customer cannot meet their loan repayments due to circumstances beyond their reasonable control, they have a legal right to apply for hardship assistance, and the bank has a legal obligation to assess that application within a defined timeframe and, where the customer qualifies, agree to a formal variation of the loan contract.

This module is distinct from informal collections arrangements (MOD-065) in a critical way: a hardship variation is a legally binding contract variation, documented, disclosed to the customer in writing, and carrying regulatory enforceability. It is not a discretionary forbearance arrangement — it is a statutory entitlement. The failure to run a compliant hardship process is a category of harm that both the FMA (NZ) and ASIC (AU) actively investigate and that generates significant enforcement action and public findings.

Regulatory framework

NZ — CCCFA section 102

The Credit Contracts and Consumer Finance Act 2003 (CCCFA) section 102 gives borrowers under consumer credit contracts the right to apply for a hardship variation. The lender must consider the application and respond within 10 working days of receiving it. If the lender agrees the borrower is facing genuine financial difficulty and is reasonably likely to be able to meet the varied terms, it must agree to the variation.

The lender may decline only on specific grounds — primarily that the borrower is not in genuine financial difficulty, or that the proposed variation would not result in a sustainable payment plan. The lender cannot decline solely because a variation would reduce the bank's expected return or increase the bank's credit risk exposure.

If the lender fails to respond within 10 working days, or declines without proper grounds, the borrower may apply to the court for a variation order. The Commerce Commission also monitors compliance with CCCFA s102.

AU — NCCP Part 4.1A

The National Consumer Credit Protection Act 2009 (NCCP) Part 4.1A (inserted by the National Consumer Credit Protection Amendment (Enhancements) Act 2012) provides an equivalent right for Australian borrowers under regulated credit contracts. Key differences from NZ:

• The assessment deadline is 21 calendar days from receipt of the application (not working days).
• ASIC Regulatory Guide 203 provides detailed guidance on responsible conduct of the hardship process.
• The bank must notify the customer in writing of its decision and, if declining, give the reasons.
• Credit default listings and court proceedings may not be initiated while a hardship application is under assessment.

Both regimes are underpinned by the same principle: a lender that offers consumer credit takes on a responsibility to assist customers through temporary financial difficulty rather than immediately escalating to collections or default proceedings.

Variation types

Variation type	Description	Effect on contract
Payment holiday	Full pause on all repayments for a defined period	Interest continues to accrue; term extends by the pause period; total interest cost increases
Reduced repayments	Minimum repayment amount reduced for a defined period	Term extends; total interest cost increases
Interest capitalisation	No repayments for a period; interest is capitalised (added to principal)	Principal balance increases; subsequent repayments recalculated on higher balance
Term extension	Same repayment amount, term extended to reduce monthly obligation	Total interest cost increases; monthly burden decreases
Partial capitalisation	Interest-only payments for a period; principal repayments deferred	Principal unchanged during period; total interest cost increases

All variation types increase the total cost of credit to the customer compared with the original contract. The variation agreement must make this explicit — the customer must be shown the revised total interest payable and total amount repayable before they accept the variation. This disclosure is produced and delivered via MOD-050.

Assessment criteria

The bank must assess three things:

1. Genuine financial difficulty — the customer is currently unable or likely to be unable to meet their repayments due to illness, injury, loss of employment, the end of a relationship, a natural disaster, or any other reasonable cause.
2. Reasonable likelihood of recovery — the customer is reasonably likely to be able to meet the varied repayment terms. A customer with no foreseeable income and no prospects of recovery may not meet this test — but the bar is low and benefit of the doubt is given.
3. Ability to meet varied terms — the proposed variation creates terms the customer can realistically afford.

The bank cannot refuse a hardship application solely because:

• The variation would reduce the bank's expected return.
• The customer has previously been in hardship.
• The customer's overall financial position is poor.
• The loan is already in arrears.

Assessors are provided with assessment guidance in MOD-053. All decisions are documented with reasons.

Data model

-- app.hardship_applications
CREATE TABLE app.hardship_applications (
  application_id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  account_id                  UUID NOT NULL,
  customer_id                 UUID NOT NULL,
  application_channel         TEXT NOT NULL CHECK (application_channel IN (
                                'app','branch','phone','written')),
  reason_category             TEXT NOT NULL CHECK (reason_category IN (
                                'job_loss','illness','relationship_breakdown',
                                'natural_disaster','other')),
  reason_detail               TEXT,
  variation_requested         TEXT NOT NULL,
  application_date            DATE NOT NULL,
  assessment_due_date         DATE NOT NULL,
  status                      TEXT NOT NULL DEFAULT 'received' CHECK (status IN (
                                'received','under_assessment','variation_offered',
                                'accepted','declined','withdrawn')),
  decision_date               DATE,
  assessor_id                 UUID,
  decision_notes              TEXT,
  variation_agreement_document_id UUID,  -- MOD-073 document reference
  created_at                  TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- app.hardship_variations
CREATE TABLE app.hardship_variations (
  variation_id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  application_id        UUID NOT NULL REFERENCES app.hardship_applications(application_id),
  account_id            UUID NOT NULL,
  variation_type        TEXT NOT NULL CHECK (variation_type IN (
                          'payment_holiday','reduced_repayments','interest_capitalisation',
                          'term_extension','partial_capitalisation')),
  original_repayment    NUMERIC(18,2) NOT NULL,
  varied_repayment      NUMERIC(18,2) NOT NULL,
  variation_start_date  DATE NOT NULL,
  variation_end_date    DATE NOT NULL,
  capitalised_amount    NUMERIC(18,2),
  status                TEXT NOT NULL DEFAULT 'active' CHECK (status IN (
                          'active','completed','defaulted')),
  confirmed_at          TIMESTAMPTZ,
  created_at            TIMESTAMPTZ NOT NULL DEFAULT now()
);

assessment_due_date is calculated at the point of application creation: 10 working days from application_date for NZ accounts, 21 calendar days for AU accounts. The jurisdiction is determined from the account's product configuration. This field is immutable after creation — it records the statutory deadline, not an internal target.

capitalised_amount is populated for interest_capitalisation and partial_capitalisation variation types only. It records the total interest amount that was added to the principal balance on commencement of the variation.

Key operations

Application submission

A customer submits a hardship application via any channel — app self-service, calling the phone banking team, visiting a branch, or sending written correspondence. The application must record the channel (for audit) and the reason category.

On submission, the system:

1. Creates the hardship_applications record with status = received.
2. Sets assessment_due_date based on the jurisdiction of the account.
3. Creates a case in MOD-053 with case_type: hardship_application, linking the application_id.
4. Emits a bank.app.hardship_application_received event.

Collections suspension

If the account has any active collections activity in MOD-065 (e.g., a late payment workflow, outbound contact schedule, or default notice in preparation), the hardship application suspends all collections activity immediately. The suspension is maintained until either:

• The application is declined and the suspension period has elapsed, or
• A variation agreement is confirmed and active.

No default notice, credit default listing, or legal proceedings may be initiated while a hardship application is under assessment. This is a legal prohibition in both NZ (CCCFA) and AU (NCCP), not a discretionary policy.

Assessment workflow in MOD-053

The hardship application case in MOD-053 follows a structured assessment workflow:

• The assessor reviews the customer's account history, income, and stated reason for hardship.
• The assessor records their assessment of the three criteria (genuine difficulty, likelihood of recovery, ability to meet varied terms).
• If granting: the assessor selects the variation type and parameters, and the system generates a variation offer.
• If declining: the assessor records the specific grounds for the decline. The customer is notified in writing with the reasons and information about their right to seek an independent review.

Alert thresholds via MOD-063:

• 5 working days before assessment_due_date: alert to assessor and supervisor.
• On assessment_due_date if status is still received or under_assessment: escalation alert to supervisor.
• If deadline is missed: immediate escalation to the head of the collections and hardship team; the case is flagged as a potential regulatory breach and logged accordingly.

Variation offer and customer acceptance

The variation offer is presented to the customer with a disclosure document produced by MOD-050. The disclosure shows:

• The current loan terms.
• The proposed varied terms, including the repayment amount during the variation period.
• The variation end date.
• The revised total interest payable and total amount repayable over the full loan term.
• The effect of any capitalised interest on the principal balance.

The customer must explicitly accept the variation offer — acceptance by silence or inaction is not permitted. Acceptance is recorded with a timestamp in the hardship_applications record.

Schedule regeneration and variation activation

On customer acceptance, the following steps execute atomically:

1. MOD-112 recalculates the amortisation schedule under the varied terms.
2. MOD-050 delivers the formal variation agreement (including the revised schedule) to the customer.
3. MOD-007 sets the hardship flag on the account and transitions the account state to hardship_variation.
4. For capitalisation variation types: MOD-001 posts the capitalised interest amount to the principal balance.
5. The hardship_variations record is set to status = active and confirmed_at is recorded.

All five steps must complete before the variation is considered active. If any step fails, the entire operation is rolled back.

Variation monitoring

A daily monitoring job runs for all accounts with status = active hardship variations:

• Missed repayment detection: if a varied repayment is missed during the variation period, the back-office hardship team is alerted via MOD-063. A missed varied repayment is treated differently from a standard collections trigger — the hardship team contacts the customer to understand whether further assistance is needed.
• End-date proximity: 14 days before variation_end_date, the customer and the back-office team are notified. This allows time to either prepare for reversion to original terms or assess whether a further variation is needed.
• End-date reversion: on variation_end_date, the variation is set to status = completed and the account reverts to the original repayment terms as shown in the revised amortisation schedule generated at activation. MOD-007 clears the hardship flag. MOD-063 notifies the customer and the hardship team that the variation has ended.

Requirements

FR-617 — Statutory deadline tracking: the system shall record the statutory assessment deadline on every hardship application at the point of submission — 10 working days from receipt for NZ (CCCFA s102), 21 calendar days for AU (NCCP Part 4.1A) — and must alert the assessor via MOD-063 at 5 days before the deadline and again at the deadline if no decision has been recorded; the application status must be escalated to a supervisor if the deadline is missed.

FR-618 — Collections suspension: the system shall suspend all collections activity from MOD-065 for an account once a hardship application is received, maintaining the suspension until either the application is declined or a variation agreement is confirmed and active; no new collections escalation, default notice, or credit default listing may be initiated during the hardship assessment period.

FR-619 — Atomic variation activation: the system shall, upon a hardship variation being accepted by the customer, regenerate the loan's amortisation schedule via MOD-112 reflecting the varied terms, deliver the updated schedule to the customer via MOD-050 as the formal variation agreement, set the account's hardship flag in MOD-007, and post any capitalised interest amount via MOD-001 — all steps completing atomically before the variation is set to active status.

FR-620 — Variation monitoring: the system shall monitor active hardship variations daily and must alert the back-office hardship team via MOD-063 when: a customer misses a varied repayment during the variation period; the variation end date is within 14 days (advance notice to customer and staff); and when the variation period ends (triggering reversion to original terms or assessment for a further variation if needed).

---

Module dependencies

Depends on

Module	Title	Required?	Contract	Reason
MOD-053	Case & complaint management module	Required	—	The hardship application creates a case in the case management module; the assessment and decision workflow is managed within MOD-053.
MOD-112	Amortisation schedule engine	Required	—	The amortisation schedule is recalculated after a variation is confirmed, showing the revised repayment schedule under the varied terms.
MOD-050	Disclosure enforcement module	Required	—	The formal variation agreement and revised schedule are delivered to the customer via the disclosure management module.
MOD-007	Account state machine	Required	—	The hardship flag is set on the account and the account state machine manages the hardship_variation state.
MOD-065	Credit servicing & collections	Optional	—	If the customer is already in the collections workflow, the hardship application suspends collections activity during the assessment period.

Required by

(No modules in this wiki currently declare a dependency on this module.)

---

Policies satisfied

Policy	Title	Mode	How
CON-008	Financial Hardship Policy	GATE	Hardship applications must be assessed within the statutory timeframe (NZ CCCFA: 10 working days; AU NCCP: 21 days); the system tracks and enforces these deadlines with escalation on breach.
CON-004	Product Disclosure & Sales Practice Policy	AUTO	The customer receives a formal variation agreement documenting the new terms, the duration of the variation, and the effect on their total interest payable before the variation is applied.
CRE-004	Loan Origination Standards	LOG	All hardship applications, assessments, decisions, and variation agreements are logged for regulatory examination and responsible lending audit.
CON-003	Vulnerable Customer Policy	AUTO	Hardship customers are flagged as vulnerable in MOD-007 and all communications are managed with empathy protocols during the variation period.

---

Capabilities satisfied

(No capabilities mapped)

---

Part of SD08 — Customer App & Back Office Platform Compiled 2026-05-22 from source/entities/modules/MOD-139.yaml