A blank capability entry should not become permission to proceed. For multi-custodian operations, settle that control before expanding the catalogue: if support cannot be established for a client, account and product context, route the case to an accountable reviewer.
The combination count bounds a planning exercise. Approval requires a different record: the applicable rule, its evidence, the account assignment and any outstanding conditions. Our recommended operating model keeps these distinct and treats each custodian as an operational counterparty with specific requirements, not a replaceable bank label.
Count the space without mistaking it for the operation
Consider a hypothetical catalogue: 3 custodians × 4 client classifications × 5 products = 60 potential tuples. Each tuple selects one member of each set. The Cartesian product contains every such selection before constraints. This is arithmetic, not an industry statistic or an estimate of workload.
The count is an upper bound for those three catalogue dimensions only. It does not imply that all triples are supported, equally frequent, equally complex or cost-equivalent. Account context and product versions may require further distinctions. Operational support also does not establish legal product suitability.
Selections before constraints.
Paths with explicit support in the relevant context.
Actual links among clients, accounts and product versions.
Evidence and work required by each workflow.
Checks of decisions, failures and transitions.
One count cannot stand in for the others.
Keep potential combinations, supported combinations, live assignments, operational work and test cases separate.Do not assume one supported combination means one live assignment, one document pack or one test. Plan work from assignments and workflow requirements. Plan tests from the decisions and failure paths that need assurance.
Model the relationships that the bank field hides
Give client legal entities, custodian legal entities, custodial accounts, products, product versions and workflows stable identifiers. Allow a client to hold multiple custodial accounts with different custodians and multiple products through explicit relationship records. Keep classification contextual: record the jurisdiction, account scope, evidence and effective period where these alter a decision, rather than treating classification as an immutable client label.
Link classification records and account relationships.
Link accounts and sourced capability requirements.
Preserve client relationships and external identifiers.
Reference the product version and assignment validity.
Link relevant accounts, assignments, decisions and tasks.
Represent multiple accounts and products as relationships, not a bank field.
Recommended records separate identity, account relationships, product assignments and the work performed against them.A relational implementation can hold these links in junction tables instead of comma-separated values. PostgreSQL documents a many-to-many pattern using foreign keys and a composite primary key. That supports the implementation technique, not a prescribed custody model.
Interactive Brokers provides a narrow illustration: its non-professional-advisor structure links a master account to individual client accounts, with the master used for fee collection and trade allocations. Preserve such relationships where they apply. This provider-specific structure is not a template for every custodian.
Designate an authoritative source for each fact. We recommend the platform for client identity and internal approval state, approved custodian contracts and documentation for capability and onboarding requirements, the product catalogue for product definitions, and approved commercial terms for fees. For custody reconciliation, retain inbound identifiers and statuses alongside their internal mappings. Resolve discrepancies against the designated authority rather than letting the latest message overwrite an unrelated approval.
Make support an explicit, reviewable decision
Use a versioned rule registry or operational capability matrix. Evaluate the base tuple with the context that changes the outcome, such as legal entity, jurisdiction, currency, channel or environment. Add dimensions because they affect a decision, not simply because the data is available. Keep capability decisions separate from required legal or suitability assessments.
- Scope and outcome: allowed, blocked, unknown or exception-reviewed.
- Required evidence, documents and conditions for progression.
- Fee schedule reference, integration route and service owner.
- Approved source reference, rule version and valid dates.
- For exceptions, the approval, precise scope, accountable owner and expiry.
The fictional entries below illustrate the record shape, not real counterparty capabilities. Names, products and source references are placeholders. Each example uses rule version A, effective from a hypothetical release date; a live registry must record the actual date.
Documented route, subject to evidence. Source: fictional Alder capability schedule, revision A. Rule A, effective from release date.
Requested channel excluded. Source: fictional Birch channel schedule, revision A. Rule A, effective from release date.
Context not covered. Source: fictional Willow onboarding guide, revision A. Rule A, effective from release date.
Design examples only, not product-suitability findings.
Hypothetical tuples distinguish documented support, an explicit exclusion and missing support.Define “allowed” as a documented operational path, not confirmation that the client has completed its conditions. Unknown should create a review task naming the missing evidence and responsible owner. Contradictory matches should also stop automatic progression. Reserve exception-reviewed for a recorded, scoped approval, not a general supported status.
If the implementation uses PostgreSQL, a CHECK constraint alone does not reject missing values: its expression is satisfied when it evaluates to true or null. Use NOT NULL where a value is mandatory. These database controls do not replace operational validation. If incomplete records must be retained, give them an explicit unresolved state and prevent progression.
Version the rule, not another workflow copy
Prefer a common workflow with scoped requirements and overrides to a template for every tuple. Define override precedence and conflict handling. A document-request step can remain common while its required documents, route and owner come from the applicable rule. A missing match must still lead to review.
Before activating a rule, define its approval status, full scope and effective interval. Specify the boundary convention, such as an inclusive start and exclusive end, and the operation date that will be evaluated. Detect overlapping or contradictory rules before activation.
At the decision or execution point, validate that the applicable rule covers the selected context and date. A reference to an existing rule record alone does not establish current permission. Bind an authorised action to its reviewed version, or revalidate that version and the action together before execution; send stale requests back to review.
Preserve a decision snapshot containing the evaluated context, applied rule version, evidence references, outcome and approver where required. Record both the decision time and the rule’s effective date, plus any exception expiry. Retain the snapshot when a later version replaces the rule.
Before activating a material change to a rule, source requirement, product version or account mapping, identify affected assignments and open workflows. Require the accountable owner to determine which approvals need invalidation, which cases need review and which may continue under documented conditions. Exception expiry should trigger a controlled decision, not silently extend permission.
Test coverage after validity is known
Start with business-owned constraints and expected outcomes. A generated combination does not establish business validity. Specify high-risk supported combinations, known exclusions and unresolved paths before choosing how to cover broader interactions.
If pairwise testing is used to cover pairs of input values during broad regression, retain explicit tests for important full custodian/client/product tuples and prohibited or unknown combinations. Define the required interaction coverage before generating the test set, and check it again when invalid combinations are removed.
- Known exclusions, missing rules and contradictory matches.
- Decisions before, at and after effective-date boundaries and exception expiry.
- Multi-account reassignment without altering unrelated assignments or erasing history.
- Incomplete custodian identifier and status mappings.
- Retries without unintended duplicate assignments or tasks.
- Custodian rejection, with a visible state, retained response and follow-up owner.
Record the applied rule version, expected outcome and observed result with each test. Report coverage against the proposed release scope and affected live assignments, so the owner can see which operational paths have been checked and which remain untested.
Release the operating artifact with an owner
Use a short release manifest that links existing records rather than duplicating them. Assign one accountable operational owner and name the technical and approval responsibilities. Before releasing a changed capability or integration route, require the manifest to answer:
- What changed? Rule versions, effective dates, scope and approved sources.
- What is affected? Account mappings, product assignments, open workflows and approvals requiring review.
- What governs execution? Evidence requirements, fee references, integration routes and service owners.
- What will be reconciled? External identifiers, inbound statuses, authoritative sources and discrepancy handling.
- What was tested? Supported paths, exclusions, unknowns, boundaries and recovery behaviour, with results and coverage gaps.
- What remains exceptional? Scoped approvals, owners, expiry dates and unresolved review tasks.
- Who authorises release? The accountable owner, restrictions on release scope and the agreed response if the route fails.
If the manifest cannot establish support for part of the proposed scope, leave that part in review. The release decision should identify exactly which assignments may proceed, under which rule version, with what evidence and whose approval. Growth can then extend an explicit operating model without turning an unresolved combination into permission.
