Community account management

ID	MOD-134
System	SD01
Repo	bank-core
Build status	Deployed
Deployed	Yes
Last commit	2b41724

---

Purpose

Community account management provides the account structure, signatory governance, and KYC enforcement required to hold and operate accounts on behalf of unincorporated and incorporated associations — sports clubs, community groups, religious organisations, residents' associations, and similar entities. It enforces multi-signatory authority rules at the transaction layer, manages annual committee turnover, and satisfies the AML beneficial ownership requirements that apply to association accounts.

Context

Community and club accounts are distinct from personal accounts and from standard business accounts. The account holder is the entity — the club or association — not any individual member. Authority over the account is vested collectively in committee officers, and that committee changes on an annual cycle, often at an AGM. The platform must handle:

• Unincorporated associations — no separate legal personality; the officers are personally liable; the entity has no ACN/NZBN; the governing document is a constitution or set of rules
• Incorporated societies — a registered legal person under the Incorporated Societies Act (NZ) or Associations Incorporation Act (AU states); holds an NZBN or ABN; the governing document is the society's constitution
• Charitable entities — may be incorporated or unincorporated; registered with Charities Services (NZ) or the ACNC (AU); tax status is separate from account structure and is not recorded here
• Body corporates — unit title bodies with legislated governance structures; less common as deposit account holders but present in the portfolio

The signing rule defines how transactions are authorised. Three modes are supported: any_one (any single signatory may authorise), any_two (two distinct signatories must both approve), and all (every active signatory must approve). The signing rule is set at account opening and recorded in the core.community_accounts table; it is enforced at the transaction authorisation layer, not solely in the UI.

Regulatory considerations

AML / beneficial ownership

The AML/CFT regime requires identification of beneficial owners — individuals who ultimately own or control 25% or more of the customer entity. For most community associations this threshold is not met by any individual: no person owns a share of the club. The relevant AML concept shifts from beneficial ownership to controlling persons — the individuals who exercise effective control over the entity through their committee roles.

At account opening, the platform must:

1. Identify the entity type and obtain the governing document (constitution or rules)
2. Identify all committee officers with authority to transact on the account (the authorised signatories)
3. Complete individual eIDV (via MOD-009) for each of those signatories before the account activates
4. Record the source of authority (the resolution or excerpt from the governing document confirming each person's role)

No beneficial owner threshold calculation is applied to the entity itself. Instead, the KYC obligation is satisfied by verifying all authorised signatories individually. This approach is consistent with the FATF guidance on non-profit organisations and the AML/CFT programme requirements under the NZ AML/CFT Act 2009 and the AU AML/CTF Act 2006.

Where the entity holds a charity registration number, NZBN, or ABN, those identifiers are recorded but are not a substitute for individual signatory eIDV.

Annual turnover and KYC refresh

Committee positions rotate annually. When a new committee member is added as an authorised signatory, they must complete eIDV before they can transact. Outgoing signatories must be deactivated (valid_until = today) at the point of the authority change, not at year end. The platform provides an annual signatory refresh workflow (see Key operations) that is initiated by an existing signatory with sufficient authority.

Data model

-- The community entity attached to an account
CREATE TABLE core.community_accounts (
    community_account_id  UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    account_id            UUID NOT NULL REFERENCES core.accounts(account_id),
    entity_name           TEXT NOT NULL,
    entity_type           TEXT NOT NULL CHECK (entity_type IN (
                              'unincorporated_association',
                              'incorporated_society',
                              'charitable_trust',
                              'body_corporate'
                          )),
    constitution_document_id  UUID REFERENCES documents.vault(document_id),  -- MOD-073
    abn_acn_nzbn          TEXT,          -- nullable; unincorporated entities have none
    signing_rule          TEXT NOT NULL CHECK (signing_rule IN (
                              'any_one', 'any_two', 'all'
                          )),
    created_at            TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Authorised signatories on a community account
CREATE TABLE core.community_signatories (
    signatory_id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    community_account_id  UUID NOT NULL REFERENCES core.community_accounts(community_account_id),
    customer_id           UUID NOT NULL REFERENCES core.customers(customer_id),
    role                  TEXT NOT NULL CHECK (role IN (
                              'president', 'treasurer', 'secretary', 'authorised_signatory'
                          )),
    kyc_status            TEXT NOT NULL CHECK (kyc_status IN (
                              'pending', 'verified', 'expired', 'failed'
                          )),
    valid_from            DATE NOT NULL,
    valid_until           DATE,          -- null = currently active
    created_at            TIMESTAMPTZ NOT NULL DEFAULT now()
);

constitution_document_id references the document stored via MOD-073. abn_acn_nzbn is nullable because unincorporated associations do not have a registered identifier. signing_rule is enforced at the transaction authorisation layer; any change to the signing rule after account opening requires a new authority resolution to be uploaded to MOD-073 and is logged to MOD-047.

Key operations

Account opening

1. Collect entity name, entity type, governing document (uploaded to MOD-073), ABN/ACN/NZBN if applicable, signing rule, and the identity of all authorised signatories
2. Create a core.community_accounts record with kyc_status = pending
3. Initiate individual eIDV via MOD-009 for each signatory — each signatory receives their own eIDV flow
4. Block account activation until all signatories have kyc_status = verified
5. Once all signatories are verified, set the account to active and log the activation to MOD-047

Annual committee change workflow

1. An existing active signatory (with authority to manage the account) initiates a committee refresh
2. They upload the updated authority resolution to MOD-073
3. For each outgoing signatory: set valid_until = today; the signatory loses transaction authority immediately upon save
4. For each incoming signatory: create a new core.community_signatories record with kyc_status = pending; trigger eIDV via MOD-009
5. The incoming signatory gains transaction authority only after eIDV is verified
6. Log the complete refresh event (all additions and removals) to MOD-047 with acting staff member and timestamp

Signatory suspension

Where a signatory's eIDV expires or is downgraded, their kyc_status is set to expired. The account monitors the active signatory count against the signing rule. If the number of verified signatories falls below the minimum required by the signing rule, the account is placed in a restricted state (outgoing transactions blocked) and the account holder is notified via MOD-063. Inbound credits continue normally.

Account closure

Closure requires authorisation consistent with the signing rule. All signatories are marked valid_until = today at closure. The governing document and authority resolution remain in the document vault (MOD-073) for the retention period required by the AML/CFT programme.

Requirements

FR-597 — System shall prevent a community account from activating until all designated authorised signatories have individually completed eIDV via MOD-009 and the association's governing document (constitution or rules) has been uploaded to MOD-073; the number of required signatories and the signing rule must be set at account opening and enforced on all subsequent transactions.

FR-598 — System shall enforce the community account's signing rule on all outbound transactions: any_one allows any single signatory to authorise; any_two requires approval from two distinct signatories; all requires approval from every active signatory; the rule must be enforced at the transaction authorisation layer, not only in the UI.

FR-599 — System shall support an annual signatory refresh workflow: the account holder (existing signatory with sufficient authority) can add new signatories, deactivate outgoing signatories, and upload an updated authority resolution to MOD-073; outgoing signatories must be set to valid_until = today and must lose transaction authority immediately; the refresh event must be logged to MOD-047.

FR-600 — System shall detect when all active signatories on a community account have had their KYC status degraded below the required threshold (e.g. expired eIDV) and must place the account in a restricted state that blocks outgoing transactions until at least the minimum number of signatories for the account's signing rule have refreshed their KYC; the account holder must be notified via MOD-063.

---

Module dependencies

Depends on

Module	Title	Required?	Contract	Reason
MOD-009	eIDV & document verification	Required	—	All authorised signatories must pass eIDV independently before the account activates.
MOD-001	Double-entry posting engine	Required	—	Account transactions are posted via the double-entry engine.
MOD-073	Document vault	Required	—	The association's constitution or rules and any signatory authority resolution must be stored in the document vault.
MOD-047	Agent action logger	Required	—	All signatory and authority changes are logged to the agent action audit trail.

Required by

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

---

Policies satisfied

Policy	Title	Mode	How
AML-002	Customer Due Diligence (CDD) Policy	GATE	All authorised signatories must pass eIDV before the account activates; the account does not open with partial signatory KYC.
CON-001	Customer Fairness & Conduct Policy	AUTO	All authorised signatories receive account communications and statements simultaneously.
GOV-006	Internal Audit Policy	LOG	All signatory additions, removals, and authority changes are logged immutably with the date and acting staff member.
PRI-001	Privacy Policy	AUTO	Each signatory's personal data is processed with individual consent; their data is not shared with other signatories beyond the minimum necessary.

---

Capabilities satisfied

(No capabilities mapped)

---

Part of SD01 — Core Banking Platform Compiled 2026-05-22 from source/entities/modules/MOD-134.yaml