Power of attorney and third-party authority¶


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

Purpose¶

Manages the registration, management, and revocation of formal and informal third-party authority arrangements on customer accounts. Supports three authority types:

Power of Attorney (PoA) — a general authority granted by the account holder while they have legal capacity. Takes effect immediately on registration.
Enduring Power of Attorney (EPoA) — a statutory instrument that continues or activates when the grantor loses capacity. May be registered while dormant and activated later on evidence of incapacity.
Informal / limited third-party authority — a bank-level authority granted by the customer for a defined scope (e.g. a family member can make deposits but not withdrawals). Not a statutory instrument; governed solely by the bank's terms and the customer's written consent.

All three types require the appointed person to pass KYC via MOD-009 before being granted any access to the account.

Regulatory context¶

PoA and EPoA are statutory instruments and their validity is governed by legislation. In NZ: the Protection of Personal and Property Rights Act 1988 governs enduring powers of attorney for property. In AU: legislation varies by state — Powers of Attorney Act 1998 (Qld), Powers of Attorney Act 2014 (Vic), and equivalents in other states. The bank must accept validly executed PoA documents and cannot require customers to use proprietary bank forms.

ASIC and the FMA are both scrutinising banks' management of third-party authorities as a conduct risk and vulnerable customer issue. Poorly supervised PoA is a well-documented vector for elder financial abuse. Regulatory expectations include: clear audit trails for all attorney transactions, proactive monitoring for abuse patterns, and staff training to identify signs of coercion or exploitation at the point of registration.

Conduct risk¶

CON-003 (Vulnerable Customer Policy) treats EPoA activation as a signal that the account holder may be losing or have lost capacity. The abuse monitoring in this module is a first-line preventive control — not a reactive fraud detection tool. Attorney abuse (using PoA to self-deal or deplete an account) is one of the fastest-growing categories of financial harm in both NZ and AU. The module's weekly pattern analysis is designed to surface suspicious changes in attorney behaviour before significant financial harm occurs.

Authority types and scope¶

Type	Granted by	Activated when	Scope configurable	Revocable
PoA (general)	Account holder	Immediately on registration	Yes	Yes, by grantor at any time
EPoA (property)	Account holder	On incapacity (or immediately if specified in document)	Limited	Yes, by grantor before incapacity; court order required after
Third-party authority	Account holder	Immediately on registration	Yes (view / deposit / transact)	Yes, by grantor at any time

Scope levels:

view — read-only access to balances and transaction history.
deposit — can add funds; cannot withdraw or transfer.
transact — can initiate and approve transactions within the account holder's existing limits.
full — all capabilities including limit changes and account settings; used for EPoA when fully activated.

Data model¶

-- app.third_party_authorities
CREATE TABLE app.third_party_authorities (
  authority_id        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  account_id          UUID NOT NULL REFERENCES core.accounts(account_id),
  grantor_customer_id UUID NOT NULL,
  grantee_customer_id UUID NOT NULL,  -- must have a verified KYC record
  authority_type      TEXT NOT NULL CHECK (authority_type IN ('poa','epoa','third_party')),
  scope               TEXT NOT NULL CHECK (scope IN ('view','deposit','transact','full')),
  document_reference  UUID,  -- MOD-073 document ID
  status              TEXT NOT NULL DEFAULT 'active' CHECK (status IN ('pending_kyc','active','suspended','revoked')),
  granted_at          TIMESTAMPTZ,
  valid_from          DATE,
  valid_until         DATE,  -- null = indefinite
  activated_at        TIMESTAMPTZ,  -- for EPoA: timestamp when incapacity was confirmed
  revoked_at          TIMESTAMPTZ,
  revocation_reason   TEXT,
  created_at          TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- app.authority_transactions
CREATE TABLE app.authority_transactions (
  tx_id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  authority_id       UUID NOT NULL REFERENCES app.third_party_authorities(authority_id),
  transaction_type   TEXT NOT NULL,
  amount             NUMERIC(18,2),
  performed_at       TIMESTAMPTZ NOT NULL,
  channel            TEXT NOT NULL CHECK (channel IN ('app','back_office','branch')),
  created_at         TIMESTAMPTZ NOT NULL DEFAULT now()
);

authority_transactions provides the raw record of what an attorney did and when. MOD-047 provides the system-wide agent action log that cross-references these records for compliance review.

Key operations¶

Registration¶

The account holder initiates registration via the app or in-branch. They select the authority type and scope, and identify the grantee. If the grantee is not an existing customer, they complete eIDV via MOD-009. If the grantee is an existing customer, their KYC status is verified before proceeding.

For PoA and EPoA: the original document is uploaded to MOD-073. Back-office review is required to confirm the document is validly executed before the authority is activated. Status is pending_kyc until the grantee's KYC check passes, then moves to active once document review is approved.

For informal third-party authority: no statutory document is required, but the customer's written consent is recorded and stored in MOD-073. Activation is automatic once the grantee's eIDV is confirmed.

EPoA activation¶

An EPoA registered as dormant (to activate only on incapacity) remains in active status with scope restricted to view until activation. Activation is triggered by the grantee submitting evidence of the grantor's incapacity — typically a medical certificate from a registered practitioner or a court order — via the back-office channel.

A back-office agent reviews the documentation. Activation requires supervisor sign-off (two-person authorisation). On activation: activated_at is set, scope is elevated to the level specified in the PoA document, and the grantor is notified if there is any contact address on record.

Activation is an irreversible step absent a court order. The audit trail records the reviewing agent, approving supervisor, document reference, and timestamp.

Transaction tagging¶

All transactions initiated under a third-party authority are tagged at the point of initiation with the authority_id. This tag flows through to the transaction record in the core ledger and to MOD-047's agent action log, recording the grantee_customer_id as the acting party. This creates a complete, queryable audit trail distinguishing the account holder's own transactions from those made by an attorney or authorised third party.

Regulators and back-office investigators can therefore produce a full history of attorney actions on any account, including amounts, timing, and channel, without needing to reconstruct it from narrative notes.

Abuse monitoring¶

A weekly background job runs for all accounts with active PoA or EPoA authorities. For each authority, the job calculates:

Transaction frequency in the past 30 days vs the prior 3-month baseline frequency.
Total outgoing transaction value in the past 30 days vs the prior 3-month baseline value.

If either metric has increased by more than 3× relative to baseline, the job emits a bank.app.authority_abuse_alert event. A case is created in MOD-053 with case_type: potential_attorney_abuse. The back-office vulnerable customer team is notified via MOD-063 for manual review.

The 3× threshold is configurable via a feature flag. The default is intentionally sensitive — false positives are preferred over missed abuse. Back-office staff close false-positive cases with a documented reason.

Revocation¶

For PoA and third-party authorities: the grantor revokes via the app. Revocation is immediate — status = revoked, revoked_at is set, and the grantee's access is removed from all channels in the same transaction. The grantee is notified of the revocation.

For EPoA after incapacity is confirmed: the grantor cannot self-revoke. Revocation requires either a written revocation instrument executed by the grantor before incapacity was confirmed (if the timing is unambiguous) or a court order. Court order documents are stored in MOD-073. Back-office activation of court-order revocation requires the same two-person authorisation as EPoA activation.

Requirements¶

FR-569 — Authority registration with KYC gate: no third-party authority may be set to active status until the grantee holds a verified KYC record; the system must enforce this at the data layer, not only in application logic.

FR-570 — EPoA activation workflow: EPoA activation must require submission of incapacity evidence to MOD-073, back-office review, and supervisor sign-off; activation without all three steps must be technically blocked.

FR-571 — Transaction tagging under authority: every transaction initiated by an attorney or authorised third party must carry the authority_id in the transaction record and be logged to MOD-047 with the grantee's identity; untagged attorney transactions must be treated as a system error.

FR-572 — Abuse monitoring: the weekly monitoring job must run for all accounts with active PoA or EPoA authorities; detection thresholds must be configurable; alerts must create a MOD-053 case within 24 hours of detection.

Module dependencies¶

Depends on¶

Module	Title	Required?	Contract	Reason
MOD-009	eIDV & document verification	Required	—	The appointed attorney or third-party authority holder must pass eIDV before they can access or transact on the account.
MOD-073	Document vault	Required	—	The PoA document, EPoA document, or authority letter is stored in the document vault as a required record.
MOD-047	Agent action logger	Required	—	All transactions made under a third-party authority are tagged with the authority holder's identity in the agent action log.
MOD-053	Case & complaint management module	Optional	—	Suspected attorney abuse cases are escalated to the case and complaint management module for investigation.

Required by¶

Module	Title	As	Contract
MOD-138	Deceased customer and estate management	Optional enhancement	—

Policies satisfied¶

Policy	Title	Mode	How
CON-003	Vulnerable Customer Policy	`AUTO`	Third-party authorities are monitored for abuse patterns — a sudden increase in transaction frequency or value by an attorney triggers an alert to the back-office team for review as a potential vulnerable customer concern.
AML-002	Customer Due Diligence (CDD) Policy	`GATE`	Any new third-party authority — whether PoA, EPoA, or informal authority — requires a KYC check on the appointed person before they can transact on the account.
PRI-001	Privacy Policy	`GATE`	The account holder's consent is required before any third-party authority is registered — except where a court order provides the authority directly.
GOV-006	Internal Audit Policy	`LOG`	All third-party authority registrations, amendments, revocations, and transactions made under authority are logged immutably to the audit trail.

Capabilities satisfied¶

(No capabilities mapped)

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