Task: Define holding company treasury data model additions

• Company: acme_group (companies.json already has is_holding: true, jurisdiction GB, HQ London – so GBP is the natural group functional /reporting currency, matching acme_uk's own GBLO business centre).
• One business unit, DIVISION type (parallel to how each office's top-level unit is a DIVISION – "Global Markets", "Risk Management"): unit_code acme_group.treasury, name "Group Treasury", business_centre_code GBLO, parent_business_unit_code null. DESK was considered (its description, "direct owner of books", fits) but DIVISION keeps this a single top-level unit without inventing a deeper desk hierarchy the holding company doesn't need yet – a DESK/BUSINESS_AREA split under it can be added later if the group ever needs more than one treasury desk.
• One portfolio: portfolio_code acme_group.treasury, name "Group Treasury Portfolio", owner_unit_code acme_group.treasury, aggregation_ccy GBP, parent_portfolio_code null, is_virtual true (matches the existing per-office top-level portfolios).

• Two books under that portfolio, both regulatory_book_type "Banking" (not "Trading" – these aren't held-for-trading positions; Banking is the correct prudential classification for financing and for hedges of non-trading/banking-book exposure, which is exactly what both of these are):

  1. "Group Intercompany Loans" – functional_currency GBP, is_sweepable false, cost_center CC-GROUP-TREASURY. Holds intercompany loans/deposits between the holding company and its subsidiaries.
  2. "Group FX Hedges" – functional_currency GBP, is_sweepable false, cost_center CC-GROUP-TREASURY. Holds FX forwards/swaps hedging remittance and translation exposure back to the group's reporting currency.

  No nostro-sweep book (acme_uk's "GBP Nostro Sweep" pattern) at this stage – cash sweeping is an operating-office concern; add one here only if a later task actually needs it.

Two options were on the table (see the story's original framing): (a) make FX driver ticks tenant-wide for CRM-matching purposes, regardless of which party's feed_binding produced them; (b) give the holding party its own parallel feed_binding for the same driver pairs.

Decision: (a), tenant-wide consumption. Reasoning:

• FX/IR market data is not genuinely party-specific – a EUR/USD print is the same real-world rate regardless of which office's feed_binding happens to be subscribed to it. feed_binding's party_id looks like it tracks who set up the binding (provenance), not who's allowed to consume the resulting ticks – treating it as a consumption gate was very likely accidental, not a deliberate multi-tenant isolation boundary.
• Option (b) would duplicate the same external rate as N separate NATS subscriptions and N separate market_observations rows per tenant (one per party that wants to see it), for data that is identical across all of them – wasteful, and every new party needing FX visibility would need its own copy of every feed re-created, which doesn't scale.
• Safety check: this does NOT leak data across party boundaries. crm_ingest_bridge::update() only ever populates a (tenant, party) engine that already exists – built from that party's own crm_topology_config/crm_driver_pair rows, which are already RLS-gated (crm_driver_pairs_tbl_party_isolation_policy: only parties in ores_iam_visible_party_ids_fn() see them). Feeding a matching tick to every tenant engine that already independently configured that same currency pair as a driver edge doesn't grant any party visibility into a pair it hadn't already configured for itself; it just makes an already-authorized engine actually receive the data.
• Implementation shape: feed_ingest_loop.cpp's tick handler (subscribe_binding_locked, .cpp:237-255) currently calls crm_bridge_->update() with a single party_uuid taken from the originating feed_binding. crm_ingest_bridge::update() should instead iterate every party within the tick's tenant_id in its engines_ map (not look up one specific (tenant, party) key) and feed each matching engine – each engine's own rate_engine::update() already no-ops (caught std::invalid_argument) for a pair that isn't one of its configured driver edges, so this is safe to call broadly. The resolve-crm-feed-binding-party-scoping task implements this.