v1.0.5 — Per-Organisation Configuration for SUN & Accounts

Release v1.0.5 lays the configuration foundation for the multi-tenant Direct Debit service. Every letting-agent organisation now has a dedicated configuration record that ties together their Modulr and Griffin account identifiers, fund-forwarding behaviour, reserve rules, and alert recipients — all manageable via API.

Why This Matters

The Direct Debit service is multi-tenant by design. Each letting agent operates under their own Modulr Service User Number (SUN) and holds funds in their own set of accounts. Without per-organisation configuration, none of the core fund-flow steps — collection, sweep, hold, forward — can be executed correctly. This release provides the data layer and admin API to set that configuration up.

What Was Added

customer_configs Table

A new database table, customer_configs, is introduced with a one-to-one relationship to the organizations table. It stores everything needed to operate the DD lifecycle for a given letting agent:

Field	Type	Description
modulr_sun	string	Modulr Service User Number — identifies the org in BACS
modulr_collection_account_id	string	Modulr account where collected tenant funds land
griffin_holding_account_id	string	Griffin DD holding account for the sweep-and-hold step
griffin_client_account_id	string	Griffin client account funds are forwarded into
hold_period_hours	integer	Hours to hold funds before forwarding (default: 24)
clawback_reserve_risk_factor	decimal	Multiplier applied to recent collection volume to size the reserve
reserve_minimum_threshold	decimal (GBP)	Hard floor for the clawback reserve balance
alert_recipient_emails	string[]	Email addresses notified when alert thresholds are breached

organizations Table Extension

The organizations table has been extended to support linkage to the new customer_configs record.

Admin tRPC API

Two admin-scoped tRPC procedures are available immediately:

customerConfig.get

Returns the full configuration record for the authenticated organisation.

// Example usage
const config = await trpc.customerConfig.get.query();
console.log(config.hold_period_hours); // 24
console.log(config.alert_recipient_emails); // ["finance@agency.co.uk"]

customerConfig.update

Updates one or more fields on the organisation's configuration record.

// Example: update hold period and add an alert recipient
await trpc.customerConfig.update.mutate({
  hold_period_hours: 48,
  alert_recipient_emails: ["finance@agency.co.uk", "ops@agency.co.uk"],
});

Both procedures are restricted to admin-role users and are strictly scoped to the caller's organisation — no cross-tenant access is possible.

Configuration Defaults

Field	Default
hold_period_hours	24
All other fields	Must be explicitly set

Note: An organisation cannot participate in collection or fund-forwarding workflows until a customer_configs record is present and all required account IDs are populated.

Database Migration

This release includes a migration that:

1. Creates the customer_configs table.
2. Extends the organizations table with the config linkage.

Run your migration tool before deploying the updated service.

Related Fund Flow Steps

The fields introduced in this release directly gate the following fund-flow operations:

• Collection — requires modulr_sun and modulr_collection_account_id
• Sweep to Holding — requires griffin_holding_account_id
• Forward to Client — requires griffin_client_account_id, hold_period_hours, clawback_reserve_risk_factor, and reserve_minimum_threshold
• Alerting — requires alert_recipient_emails