Strategic Transformation Dossier
Decisioning Engine
Adoption Failure Analysis
Adoption Failure Analysis
A structured diagnostic of platform adoption barriers, root cause identification, and the automation and agentic roadmap required to unlock the platform's intended operational value.
10%
Data fields accessible to engine (500 of 5,000)
2 of 4
Channels integrated; SMS & email excluded
1 of 3
Product portfolios covered; mortgages & deposits excluded
Operating Context
The environment the platform entered
Understanding the organisational and technical conditions that shaped adoption failure · and why these are systemic issues, not platform deficiencies.
Data Warehouse Fields
5,000
Total available decision signals
Fields Mapped to Engine
500
10% of available signal set
Contact Policy Mode
Batch
Not real-time; creates loopholes
Contact History Sync
Manual
Batch file lift-and-shift between platforms
The Tibco decisioning platform was introduced as the institution's primary tool for customer-level marketing automation. The commercial intent was sound: a single decisioning engine that could orchestrate cross-product, omnichannel customer engagement at scale.
However, the platform was stood up without the data infrastructure, channel integration breadth, and real-time operational backbone that a decisioning engine of this nature requires. The result is a technically capable platform operating at a fraction of its intended capacity · creating frustration across marketing, technology, and compliance teams, and eroding confidence in the investment.
It is important to frame this correctly for leadership: the platform is not broken · it is incomplete. The distinction is critical. A broken platform requires replacement. An incomplete one requires structured completion · which is precisely what this dossier provides.
Next Step
Review the full operational context before entering the diagnostic phase
Root Cause Diagnosis
Five structural failure points
Each problem compounds the others. Data gaps feed channel gaps. Channel gaps undermine contact policy. Contact policy failure creates regulatory exposure. This is a system-level challenge, not a configuration one.
01
Data Coverage Gap
Only 10% of available data signals reach the decisioning engine
High Impact
⌄
The data warehouse contains 5,000 fields representing a comprehensive picture of every customer across all products, transactions, channels, and lifecycle events. The decisioning engine can access only 500 of them · 10% of the available signal set.
This isn't merely a data engineering inconvenience. Every decision rule, propensity model, segmentation framework, and suppression logic in the platform is built on an incomplete view of the customer. The engine cannot perform full lifecycle campaign execution because the triggers that initiate lifecycle events · behavioural signals, product events, risk indicators · sit in the unmapped 90%.
Strategic implication: Without customer-level, transaction-level, card-level, and product-level data all available simultaneously, the engine defaults to coarse product-level decisions. This directly limits personalisation fidelity, model accuracy, and segment granularity.
The resolution path requires a prioritisation exercise: identify the 50–100 decision-critical fields from the unmapped 4,500 and automate their ingestion pipeline. This is a data engineering task, not a platform task.
02
Channel Fragmentation
SMS and email operate on a separate platform with no unified execution
High Impact
⌄
The Tibco platform currently executes direct mail and telemarketing · both inbound and outbound. SMS and email, the two highest-frequency and most measurable digital channels, operate on a separate platform entirely. There is no native integration pathway.
This breaks the fundamental commercial promise of a decisioning engine: a single point of orchestration where the right message, delivered on the right channel, at the right moment, is determined from a unified logic layer. With two systems operating independently, neither can claim that guarantee.
Critical exposure: Because SMS and email exist outside Tibco's contact visibility, the contact frequency rules cannot account for communications sent through those channels. A customer might receive 2 telemarketing contacts through Tibco and 3 email contacts through the other platform · breaching policy limits the engine has no way to detect.
03
Product-Centric Architecture
Built for consumer lending only; mortgages and deposits are invisible
Strategic
⌄
The platform's data model and decision logic were structured around a single product portfolio · consumer lending, predominantly credit cards. Mortgages and deposit accounts sit outside the decisioning perimeter entirely.
This is an architectural issue, not a configuration one. When the decisioning entity is the product rather than the customer, it becomes structurally impossible to generate cross-portfolio insights, relationship-level decisions, or lifetime value calculations that reflect the complete customer relationship.
Consider the practical consequence: a customer at high mortgage retention risk, who also holds a credit card nearing its limit, should receive a fundamentally different message than a credit-card-only customer in the same product state. The current architecture cannot distinguish them.
Resolution path: Migrate the data model from product-entity to customer-entity. Every product holding becomes an attribute of the customer record. This is a data architecture initiative · once completed, it unlocks cross-portfolio decisioning without requiring platform replacement.
04
Contact History Synchronisation
Manual batch file transfer between platforms; real-time decisioning is impossible
High Impact
⌄
Two customer engagement platforms maintain two separate contact history stores. Reconciling them requires a manual process: extracting data from one platform, transforming it into a batch file, and loading it into the other. This happens on a scheduled cadence · not in real time.
The operational consequence is that the contact history feeding the Tibco engine is always a snapshot from a fixed point in the past · never a reflection of the current moment. Any customer interaction that occurs between batch runs is invisible to the decisioning engine. Suppression rules, frequency caps, and response-triggered follow-ups all operate on stale data.
Operational risk: There is no automated validation or reconciliation check on the batch file transfer. If the transfer fails silently, campaigns continue executing against contact history that may be hours or days out of date. There is no alerting mechanism.
05
Contact Policy Calculation Flaw
Batch-mode frequency check creates a counting loophole · with regulatory consequences
Critical
⌄
This is the most operationally dangerous problem identified. The contact frequency policy check reads from a previous day's count · not from a running real-time total. This creates a concurrency loophole that allows multiple batch jobs, executed within the same processing window, to each pass the policy check independently · even when their combined output would breach the weekly contact limit.
Failure Mode Simulation · Policy: max 3 contacts per week
| Event | System Check | Result | Running Total |
|---|---|---|---|
| Day 1: 2 contacts sent | · | · | 2 |
| Day 2, Batch Job A runs | Reads yesterday: 2 < 3 | Approved ✓ | 3 |
| Day 2, Batch Job B runs (same window) | Still reads yesterday: 2 < 3 | Incorrectly approved ✗ | 6 · breach |
| Policy limit breached | Not detected | Overcommunication sent ✗ | 6 of 3 allowed |
Regulatory exposure: Systematic overcommunication resulting from a calculation flaw is not merely an operational problem · it represents a potential breach of customer consent and communication frequency commitments. This must be treated as a compliance risk requiring urgent remediation.
The fix requires replacing the batch count reference with an atomic real-time counter. Every contact event writes to a shared reference table at the moment of dispatch. Before any subsequent contact is permitted, the system reads the current count · not yesterday's. The counter must be atomic (lock-read-increment-write) to prevent race conditions across concurrent jobs.
Compliance Review
The contact policy flaw requires priority attention from Risk & Compliance leadership
Transformation State
Before and after the intervention
The operational delta between the current degraded state and the target architecture · across data, channels, decisioning, and compliance posture.
⬤ Current state · operational gaps
Only 10% of warehouse data signals available · decisioning is data-blind on 4,500 fields
SMS and email execute independently with no visibility from the decisioning engine
Contact history reconciled manually via batch file · real-time decisioning structurally impossible
Contact frequency policy uses stale daily counts · loophole allows systematic overcommunication
Decisioning entity is the product · cross-portfolio and relationship-level decisions are absent
No platform observability · silent failures are undetected; no alerting on sync delays or policy breaches
Mortgages and deposit accounts are entirely invisible to the decisioning layer
⬤ Target state · post-intervention
Priority data fields automatically ingested and mapped · decision-critical signals fully available
Unified channel orchestration layer routes Tibco decisions to all four channels including SMS and email
Event-driven contact history sync · both platforms subscribe to a shared real-time contact event bus
Atomic real-time contact policy counter · concurrent jobs check live state; overcommunication is impossible
Customer-entity data model · every product holding is an attribute; cross-portfolio decisioning enabled
Agentic monitoring layer provides continuous observability · sync lag, policy breaches, and anomalies surfaced automatically
All product portfolios · cards, mortgages, deposits · unified under a single customer decisioning record
Architecture Review
Evaluate the feasibility of the target architecture for your infrastructure
Automation Architecture
Five remediation automations
Each automation is scoped to a specific root cause. Together they form the operational backbone that makes the platform perform as intended.
Automated Data Field Pipeline
Resolves: Data coverage gap · Priority-ranked ingestion of decision-critical fields
Build an automated data integration pipeline that progressively exposes warehouse fields to the decisioning engine · beginning with the fields that generate the highest decisioning uplift. Business and analytics teams gain a self-service field catalogue to request new fields without requiring engineering intervention.
- →Score and rank all 5,000 fields by decisioning relevance using model usage frequency, campaign dependency, and business request volume
- →Automated pipeline syncs priority-ranked fields to Tibco on a defined schedule with embedded data quality validation
- →Field catalogue with a self-service request workflow · business teams submit field requirements without raising engineering tickets
- →Distribution drift monitoring · alerts when field value distributions shift beyond expected thresholds, indicating upstream data changes
Unlocks customer-level decisioning
Improves model signal quality
Reduces engineering dependency
Real-Time Contact Policy Engine
Resolves: Contact policy flaw · Atomic counter replaces batch frequency check
Replace the batch contact frequency check with an event-driven, atomic counter that updates at the moment of every contact event. Every channel · including the external SMS and email platform · must perform a pre-flight API call before any communication is dispatched.
- →Real-time contact event bus: every dispatch event triggers an immediate write to a shared contact ledger
- →Pre-flight policy check: API call required before any message is sent · blocks dispatch if the limit has been reached
- →Atomic read-increment-write pattern: locks the counter during update to prevent race conditions across concurrent jobs
- →Rolling window calculation: "contacts in the last 7 days" rather than "contacts sent yesterday" · eliminates the counting loophole entirely
- →Cross-channel visibility: the SMS/email platform must call the same API, making contact policy universal
Eliminates overcommunication loophole
Regulatory compliance restored
Cross-channel policy unified
Unified Channel Orchestration Layer
Resolves: Channel fragmentation · Middleware routes Tibco decisions to all four channels
Introduce an orchestration middleware layer that sits between Tibco and all delivery channels. Tibco retains its role as the decisioning authority; the orchestration layer routes each decision output to the appropriate channel · including SMS and email · without requiring native integration of those channels into Tibco.
- →Tibco produces a next best action decision object: customer ID, channel preference, message content reference, timing parameters
- →Orchestration layer receives the decision and routes to direct mail, telemarketing, SMS, or email platform accordingly
- →All delivery confirmations · sent, bounced, opened, clicked · feed back into the shared contact ledger
- →Suppression state and opt-out flags are shared across all channels via a unified API
Near-term achievable without platform replacement
Full channel visibility
Unified suppression logic
Customer-Entity Data Model Migration
Resolves: Product-centric architecture · Customer becomes the decisioning entity
Restructure the decisioning data model from product-entity to customer-entity. Every product holding · credit card, mortgage, deposit account · becomes an attribute of the customer record rather than a separate decisioning target. This enables the first true relationship-level marketing capability in the institution.
- →Customer golden record: all product holdings, lifecycle stages, and relationship attributes unified under a single decisioning target
- →Cross-portfolio signal routing: mortgage risk indicators visible during credit card decisioning; deposit withdrawal triggers visible across all products
- →Unified suppression: opt-out on any product propagates across all product communications for that customer
- →Relationship lifecycle rules: onboarding, tenure, at-risk, and churn signals evaluated at the whole-relationship level, not per product
Enables true relationship marketing
Highest long-term ROI
Cross-sell and retention unified
Real-Time Contact History Synchronisation
Resolves: Manual batch sync · Event streaming replaces file transfer dependency
Replace the manual batch file transfer with an event-driven synchronisation architecture using a message streaming backbone. Every contact event written to either platform is published to a shared event stream. Both platforms subscribe and consume events as they occur, eliminating batch lag and the manual dependency simultaneously.
- →Event streaming backbone (e.g. Kafka, Kinesis, or Azure Event Hub) becomes the authoritative contact event channel
- →Tibco and the email/SMS platform both publish contact events to and subscribe from the shared stream
- →Reconciliation job runs nightly to detect and flag any discrepancies between platform contact histories
- →Monitoring dashboard with sync lag alerting · escalates if event processing falls more than 5 minutes behind
Eliminates manual dependency
Real-time decisioning enabled
Operational resilience improved
Integration Assessment
Evaluate which automation layers are achievable within your current infrastructure
Agentic Intelligence Layer
Five agentic interventions
Agents sit above the automation layer · not replacing it, but reasoning over it. Where automation executes fixed logic, agents evaluate context, make judgements under uncertainty, and adapt their outputs based on what they observe.
Agent 1 · Data Field Prioritisation Agent
Addresses: 4,500 unmapped fields with no prioritisation framework
This agent continuously analyses which unmapped data fields are most likely to improve decisioning outcomes · before a human has to guess. It correlates field availability with campaign performance, model lift, and business team request patterns to generate an always-current prioritisation order.
How it operates
Agent ingests campaign results and warehouse metadata → identifies which missing signals correlate with poor decision accuracy → ranks unmapped fields by expected decisioning uplift → raises prioritised field mapping requests with business justification to the data engineering team → monitors field availability and triggers automated validation tests when a new field becomes accessible.
Agent 2 · Contact Policy Guardian Agent
Addresses: Batch-mode loophole + cross-channel policy blindness
This agent acts as the authoritative real-time enforcer of contact policy across all channels and all platforms. It holds the live state of every customer's contact frequency and intercepts every dispatch request · regardless of which system initiates it. Where the current system checks a stale count, this agent checks the truth of right now.
How it operates
Agent maintains a real-time contact ledger per customer → any platform requesting permission to send must call the agent's API before dispatch → agent checks rolling window counts against policy rules → approves, blocks, or proposes an alternative channel → logs every decision with timestamp and rationale → detects and alerts on anomalous contact volume patterns (e.g. a runaway batch job) before harm is done.
Agent 3 · Channel Selection & Sequencing Agent
Addresses: Channel fragmentation + hardcoded channel logic in campaign rules
Rather than channel selection being hardcoded in campaign rules, this agent determines the optimal channel · and the optimal sequence of channels · for each customer decision in real time. It evaluates response history, contact capacity per channel, customer preference signals, and message urgency to make a contextual recommendation at the moment of need.
How it operates
Tibco produces a next best action → agent receives the decision along with the customer profile → evaluates channel preference (opt-in data), response history (email open rates, SMS click rates), remaining contact capacity per channel, and message urgency → selects the optimal channel and timing window → if the first channel produces no response within N days, the agent triggers an automatic follow-up via a secondary channel, within policy limits.
Agent 4 · Customer Journey Orchestration Agent
Addresses: Product-centric architecture + fragmented lifecycle automation
This agent holds the customer's end-to-end journey state across all products and lifecycle stages · the layer of intelligence that Tibco's product-centric architecture cannot provide. It coordinates decisions across product silos, ensuring the next best action reflects the whole customer relationship and not just the loudest product signal at any given moment.
How it operates
Agent maintains a customer journey state machine (onboarding, active, at-risk, churned) per product and in aggregate → monitors lifecycle events from all product systems simultaneously → when an event fires, evaluates cross-product implications before triggering decisioning → ensures a customer being managed through mortgage retention is not simultaneously receiving an aggressive credit card upsell · a conflict the current system has no way of detecting.
Agent 5 · Decisioning Health Monitoring Agent
Addresses: Silent operational failures + absence of platform observability
The problems identified in this engagement did not surface because there was no mechanism to detect them. This agent provides continuous observability across the full decisioning stack · surfacing sync failures, policy anomalies, model degradation, and data drift before they compound into campaign-level problems that reach customers.
How it operates
Monitors contact event lag between platforms (alerts if sync exceeds 5 minutes) → detects anomalous contact volume spikes indicative of runaway batch jobs → tracks decision rule coverage · the percentage of customers falling into "no action" due to missing data → measures policy breach rate trends over time → generates a weekly decisioning health report with root cause attribution and recommended remediation → escalates to human review when defined thresholds are breached.
Strategic Advisory
Understand how agentic architecture maps to your current platform capabilities
Department & Stakeholder Impact
Who this transformation affects
Every operational change in this architecture has named stakeholders who will experience a material shift in workload, visibility, and capability.
| Department | Current Burden | Post-Intervention Capability | Change Type |
|---|---|---|---|
| Marketing Operations | Campaign execution limited to DM and telemarketing; manual coordination with email/SMS team | Full four-channel execution from a single decisioning layer; automated channel selection per customer | Capability expansion |
| Data Engineering | Ad hoc field mapping requests with no business prioritisation; manual batch file maintenance | Priority-ranked backlog with business justification; event-driven sync eliminates batch file dependency | Workload reduction |
| Risk & Compliance | No visibility into cross-channel contact frequency; relying on manual audit of batch policy checks | Real-time policy enforcement with full audit trail; automated breach alerting before customer impact | Risk posture improvement |
| CRM / Customer Engagement | Product-level campaigns with no relationship-level view; no lifecycle coordination across products | Customer-entity decisioning spanning all products; journey orchestration agent coordinates lifecycle signals | Strategic capability unlock |
| Technology / Platform | Two platforms with manual reconciliation; no monitoring; silent failure risk | Event-driven integration backbone; continuous health monitoring; automated failover alerting | Operational resilience |
| Analytics & Decisioning | Models built on 10% of available signal set; no feedback loop from channel response data | Progressive field ingestion improves model signal quality; cross-channel response data feeds back into decisioning | Model performance improvement |
| Product Management (Mortgages, Deposits) | Entirely excluded from the decisioning platform; separate tooling with no cross-sell coordination | Full inclusion in the customer decisioning model; cross-portfolio signals inform product-specific campaigns | Platform access expansion |
Systems & Integration
Platform relationships and data flow
The current platform landscape and the integration architecture required to resolve the identified gaps.
Current Platform State
Tibco Decisioning Engine
Primary decisioning and campaign orchestration platform
Active · underutilised
Enterprise Data Warehouse
5,000 fields; 4,500 unmapped to decisioning engine
Integration gap · 90% inaccessible
Email & SMS Platform
Digital channel execution · operates independently from Tibco
No integration · siloed
Direct Mail & Telemarketing
Traditional channels · integrated natively with Tibco
Active · integrated
Contact History Store (Tibco)
Contact ledger for DM and telemarketing · batch-reconciled with external platform
Manual sync · real-time gap
Event Streaming Backbone
Required: Kafka / Kinesis / Azure Event Hub for real-time contact sync
Required · not yet deployed
Target Integration Architecture · Data Flow
Implementation Roadmap
Three-phase delivery sequence
Sequenced to address the highest-risk items first, then build the data and channel foundations, then deliver the strategic decisioning capability the platform was intended to provide.
Phase One
Stop the Bleeding
Immediate · 0 – 60 days
Deploy Contact Policy Guardian Agent · replace batch check with real-time atomic counter
Activate Health Monitoring Agent · establish observability baseline across both platforms
Compliance disclosure: notify Risk & Compliance leadership of contact policy flaw and remediation in progress
Audit historical overcommunication · assess regulatory exposure from batch loophole
Quick-win field mapping · identify and map the top 50 decision-critical fields from the unmapped 4,500
Phase Two
Build the Foundation
3 – 6 months
Automated data field pipeline · progressive ingestion of priority-ranked warehouse fields
Real-time contact history sync · replace manual batch file with event streaming backbone
Channel orchestration middleware · connect Tibco decisions to SMS and email platform
Deploy Channel Selection Agent · replace hardcoded channel rules with contextual routing
Field catalogue with self-service business access · reduce engineering dependency for field requests
Phase Three
Deliver the Vision
6 – 12 months
Customer-entity data model migration · mortgages, deposits, and cards unified under a single decisioning record
Deploy Customer Journey Orchestration Agent · cross-portfolio lifecycle management operational
Deploy Data Field Prioritisation Agent · continuous, intelligence-driven field ingestion optimisation
Full lifecycle campaign automation · onboarding, retention, cross-sell, and churn prevention operational across all products
Performance review: measure model accuracy improvement, campaign response lift, and contact frequency compliance rate
Deployment Planning
Validate the roadmap against your infrastructure constraints and resourcing model
Business Outcomes
Commercial and operational leverage
Translating the technical remediation into the outcomes that matter to executive leadership: risk reduction, operational efficiency, customer engagement performance, and platform ROI.
Contact policy compliance
100%
Real-time enforcement eliminates batch loophole entirely
Data signal coverage
10% → 60%+
Progressive field ingestion to decision-critical threshold
Channels orchestrated
2 → 4
SMS and email unified into the decisioning architecture
Manual operational steps
Eliminated
Batch file transfer, contact policy audit, field mapping requests
Compliance & Risk
Contact frequency policy enforced in real time across all channels · regulatory exposure resolved
Full audit trail on every contact decision · timestamp, channel, policy state, outcome
Automated breach alerting before customer impact · not after audit discovery
Historical overcommunication quantified and disclosed appropriately
Operational Efficiency
Manual batch file transfer eliminated · event-driven sync requires zero human intervention
Field mapping self-service reduces engineering ticket volume for data requests
Health monitoring agent catches failures before business impact occurs
Channel orchestration removes manual coordination between marketing and digital teams
Customer Engagement Performance
Contextual channel selection improves response rates · right channel, right moment, per customer
Cross-portfolio decisioning enables relationship-level personalisation for the first time
Improved model signal quality (60%+ data coverage) drives propensity score accuracy improvement
Lifecycle journey orchestration reduces customer attrition through coordinated retention signals
Platform Investment ROI
Existing Tibco investment begins returning value · the platform now operates as intended
No platform replacement required · completion, not replacement, is the resolution
Mortgages and deposits now within the decisioning perimeter · expanding the revenue base the platform supports
Agentic intelligence layer adds continuous improvement capability that compounds over time
Begin the Engagement
This dossier represents the diagnostic layer. The next step is a structured architecture review with your technology and marketing leadership.
Governance & Explainability
The layer that makes
agentic safe
agentic safe
Deploying agentic AI in a regulated financial institution without a governance architecture is not a technology decision · it is a risk event. The following chapters define the regulatory requirements, the audit log schema, the explainability approach by agent type, the three lines of defence ownership model, and the escalation protocols that make these agents audit-ready and regulator-defensible.
Chapter 11 · Regulatory Context
What the regulator actually needs
The governance framework must be designed for the hardest question first: can you answer "why did this agent make this decision for this customer on this date?" within 30 minutes, for any decision made in the past 7 years?
SR 11-7 / APRA CPG 220
Model risk management · agents as models
The US Federal Reserve's SR 11-7 and its equivalents across APRA, FCA, and EBA establish that any quantitative tool used to make consequential customer decisions is a "model" subject to governance. Agentic AI that influences customer contact frequency, product eligibility, campaign suppression, or channel routing falls squarely within this definition. The three non-negotiable requirements: independent validation before deployment, ongoing performance monitoring after deployment, and documented governance with named individual accountability at every level.
GDPR Art. 22 / Privacy Act
Right to explanation for automated decisions
Where an automated decision produces a legal or similarly significant effect on an individual, that individual has the right to a meaningful explanation of the logic involved, the significance of the decision, and the envisaged consequences. In financial services, a contact suppression decision that prevents a customer from receiving a product offer they would have materially benefited from may qualify. This means the agent's decision record must be capable of generating a human-readable explanation on demand · not reconstructed post-hoc, but pre-generated at the moment of decision and stored with the audit record.
FCA Consumer Duty / ASIC RG 168
Conduct obligations · fair treatment and customer outcomes
The FCA's Consumer Duty and ASIC's equivalent require firms to demonstrate that automated customer engagement decisions are made in the customer's genuine interest, not merely the firm's commercial interest. This means the agent's reasoning must be auditable against a "would a fair-minded regulator consider this reasonable?" standard · not merely against internal policy thresholds. The governance framework must include a defined mechanism for retrospective review of decisions that subsequently prove harmful, including a process for identifying all customers affected by any systematic decision error.
Contact compliance
Contact frequency rules as enforceable commitments
The contact policy flaw identified in this engagement is not merely operational · it represents a potential breach of the institution's stated commitments to customers regarding communication frequency. Where those commitments are referenced in product terms, privacy notices, or regulatory filings, systematic breach becomes a potentially reportable event. The real-time contact policy agent must produce auditable evidence that no customer was contacted beyond their permitted frequency, retrievable for regulatory review within 24 hours of any request. Historical overcommunication arising from the batch loophole must be quantified and assessed for disclosure obligations.
Internal audit standard
What internal audit will test
Internal audit will not test whether the agent logic is technically correct · that is second line's mandate. Internal audit tests whether the governance framework functions as documented. Specifically: (1) Can you reconstruct what any agent decided, for any customer, at any point in the past 7 years? (2) Can you demonstrate the decision was consistent with approved policy at the time it was made, not policy as it stands today? (3) Can you show who approved the agent logic, when it was last independently reviewed, and what changed between reviews? A "no" to any of these means the agent is not audit-ready, regardless of how sophisticated its logic is.
The governance test that matters most
"Can you answer why this agent made this decision for this customer on this date · within 30 minutes of being asked · for any decision made in the past 7 years?"
If the answer is no, the audit trail architecture is insufficient regardless of how well the agent logic performs.
Regulatory Advisory
Assess your current model risk framework against these agentic governance requirements
Chapter 12 · Audit Log Architecture
Decision DNA · what every log entry must contain
The audit log is not a technical artefact. It is a legal document. Every field has a regulatory purpose, and the schema must be designed with the regulator's questions in mind · not the engineer's convenience.
Field
Purpose and content
Requirement
decision_id
Globally unique, immutable UUID generated at decision time. The anchor for all downstream references · override records, complaint linkages, regulatory responses. Every other record in the system that touches this decision references this ID.
Mandatory
agent_id + version
Which agent made the decision and which exact version of its logic. If a logic error is discovered in v2.1, every decision made by v2.1 can be identified and reviewed. Version must be immutable · a deployed agent version is never overwritten, only superseded.
Mandatory
timestamp_utc
Millisecond-precision UTC timestamp. Critical for reconstructing concurrent decision sequences · particularly the contact policy race condition scenario where two batch jobs processed within the same window must be distinguishable.
Mandatory
customer_token
Pseudonymised customer identifier · not the raw customer ID. The mapping between token and real identity is held separately under strict access controls. Enables audit and analysis without creating a broad data access risk in the log store itself.
Mandatory
input_state_snapshot
A complete, point-in-time snapshot of every input the agent evaluated at the moment of decision: contact counts, policy thresholds, product states, channel capacities, model scores. Without this, the decision cannot be reconstructed · even if the agent logic is replayed · because the input state at the time no longer exists.
Mandatory
decision_taken
The specific action taken: approve / block / reroute / escalate / suppress / alert. A structured enumeration, not free text. Enables aggregate analysis: how often does the policy guardian block vs. reroute? Is the suppression rate for any customer segment anomalously high?
Mandatory
primary_reason_code
The single most material factor in the decision, expressed as a named code: contact_limit_reached, cross_portfolio_conflict, channel_capacity_exhausted, model_score_below_threshold. This is the key from which a customer-facing GDPR Art.22 explanation is generated via a pre-approved template.
Mandatory
rules_evaluated
The ordered list of policy rules checked, their input values, and their pass/fail result. This is the audit equivalent of "showing your working." A regulator can verify that the correct rules were applied in the correct sequence, and that no rule was skipped or short-circuited.
Mandatory
confidence_score
For deterministic rule-based decisions: 1.0. For model-influenced decisions (channel selection utility score, field prioritisation ranking): the model's confidence in its recommendation. Decisions below a defined confidence threshold trigger an automatic escalation flag for human review.
Recommended
shap_contributors
For model-influenced agents only: the top 3–5 SHAP feature contributions to the model score, stored at decision time. "Email selected primarily because: customer email open rate (last 30 days) = 42% vs SMS click rate = 8%; remaining email capacity = 2; message urgency = non-time-sensitive." Human-readable, regulatorily defensible.
Recommended
escalation_flag
Boolean: did this decision trigger a human review requirement? If true, links to the escalation record including the reviewer's identity, review timestamp, the original decision, the outcome of the review, and the stated justification for any override.
Mandatory
override_record
If a human overrode the agent decision: the reviewer's named identity (not a role), timestamp, the original agent decision, the override decision, and the documented justification. The override record is as important as the original · it is the primary evidence of human governance functioning as designed.
Mandatory if applicable
explainability_text
A pre-generated, plain-English explanation of the decision · rendered from the primary_reason_code via a pre-approved template at decision time, not reconstructed later. Example: "Your contact frequency limit of 3 per week was reached on [date]. No further contact was permitted until [date], when your weekly limit resets." This is the GDPR Art.22 response, generated before it is requested.
Recommended
downstream_outcome
Populated retroactively 24–72 hours after the decision: what actually happened. Customer responded / did not respond / complained / churned / converted. This is the feedback signal the Learn phase of the PRAL loop consumes. Without it, agents cannot improve · they repeat themselves indefinitely.
Strongly advised
Immutability · non-negotiable
Audit logs must be written to an append-only store · not a standard relational database table that can be updated or deleted. Every amendment, correction, or contextual addition must be a new record referencing the original via its
decision_id · never an in-place edit. A log store that permits row-level updates is not an audit log; it is a mutable record that a regulator will not accept as evidence. Architecture options: Apache Kafka with log compaction disabled, AWS QLDB, Azure Immutable Blob Storage, or a blockchain-anchored hash chain.Technical Architecture
Evaluate your current data infrastructure against the immutability and retrieval requirements
Chapter 13 · Explainability by Agent Type
Explainability is not one thing
The right explainability approach depends entirely on how the agent makes its decisions. Rule-based agents, model-influenced agents, and hybrid agents each require a different architecture. Applying a single approach across all five agents will leave gaps that a regulator or internal auditor will identify.
The Policy Guardian (A2) and Health Monitor (A5) execute deterministic logic · a finite set of conditions evaluated in a defined, human-approved order. Their decisions are inherently explainable because every step in the reasoning is a named rule. The explainability task here is completeness, not interpretation.
Approach · decision trace logging
Log every rule evaluated, in sequence, with its input values and pass/fail outcome. The explanation is a structured trace: "Rule 1 · rolling 7-day contact limit: contacts_this_week = 3, limit = 3, result = BLOCK. Rule 2 · channel-specific daily cap: not evaluated (blocked at Rule 1)." A non-technical reviewer · compliance officer, complaint handler, regulator · can follow this without needing to interpret a statistical model.
Customer-facing explanation generation
Pre-generate a plain-English explanation at the moment of decision, from a pre-approved template keyed to the primary_reason_code. This satisfies GDPR Art.22 without requiring post-hoc reconstruction · which carries the risk of the explanation not matching what was actually decided. Example: "You have received 3 contacts this week, which is the maximum permitted under our communication policy. You will be eligible to receive further communications from [date]." Template library requires legal and compliance sign-off before deployment.
Rule change management
Every change to any rule · a threshold, the evaluation sequence, a new rule addition, a rule removal · must be versioned, approved by second line, and recorded in the change log before deployment. A rule change without an audit trail is an untraceable governance gap. The agent's rule set is itself a governance artefact requiring the same change control discipline as a policy document. The change log must record: what changed, why, who requested it, who approved it, and the effective date.
The governance principle for rule-based agents: the rules are the explanation. The explainability investment is in ensuring every rule is named, documented, approved, versioned, and logged · not in building interpretability tooling on top of a system that is already transparent by design.
The Channel Selection Agent (A3) uses a learned utility scoring model to predict the probability of customer response by channel. The model is not deterministic · it weights many signals to produce a score. The decision is based on the score, but the score itself is not directly interpretable. This is the explainability challenge specific to model-influenced agents.
Approach 1 · SHAP values per decision (primary method)
SHAP (Shapley Additive Explanations) attributes each feature's contribution to a specific model prediction. For each channel routing decision, store the top 3–5 SHAP contributors at decision time: "Email was selected primarily because: (1) customer email open rate in last 30 days = 42% vs SMS click rate = 8%; (2) remaining email contact capacity = 2 of 3 weekly allowance; (3) message type classified as non-urgent, favouring email over SMS." This is regulatorily defensible and interpretable by a non-data-scientist reviewer.
Approach 2 · surrogate model for population-level explanation
Train a simple, interpretable surrogate model (shallow decision tree or logistic regression) to approximate the complex model's decisions across a representative population sample. The surrogate does not make decisions · it explains them in aggregate. Used for: regulatory model documentation, internal audit review of the model's behaviour, and identifying whether the model is using any feature as a proxy for a protected characteristic. Accepted by most financial regulators as a reasonable SR 11-7 compliance approach for complex models.
Pre-deployment model validation
Before the channel selection model enters production, it must be independently validated · by a separate team from those who built it, or an external party. The validation report must document: discriminatory power (Gini, AUC), calibration (predicted vs actual response rates), stability across customer segments (does it perform equitably across age, geography, product cohort), and absence of proxy discrimination (is channel preference being predicted via a variable that proxies a protected characteristic). This report is a permanent governance artefact, updated at every major model version.
Ongoing performance monitoring
Monitor the channel selection model monthly for distributional drift: has the distribution of input features shifted significantly since validation? Calculate PSI (Population Stability Index) across all model inputs · a PSI above 0.25 on any key feature triggers a re-validation within 30 days. Track actual vs. predicted response rates by channel monthly. If actual performance falls more than 10 percentage points below validated performance, the model is suspended pending re-training and re-validation.
The governance principle for model-influenced agents: the model is a black box; the governance surrounding it must be entirely transparent. You cannot explain internal model weights to a regulator · but you can fully explain the validation process, the feature set approved for use, the monitoring regime, and the outcomes achieved. That is what regulators actually require.
The Data Field Prioritisation Agent (A1) and Journey Orchestration Agent (A4) combine rule-based eligibility logic with model-influenced scoring. Each layer needs its own explainability approach. The governance framework must be explicit about which decisions came from which layer · ambiguity between layers is the most common audit failure in hybrid agent designs.
Layered audit logging · separating rule and model traces
The audit record must clearly distinguish between the rule layer and the model layer. Two separate structured sections within each log entry: (1) Rules evaluated · the eligibility and constraint rules, their input values, and pass/fail results; (2) Model contributions · the scoring model output and SHAP contributors for any model-influenced element. A regulator examining a Journey Orchestration suppression must be able to determine whether it was the rule layer (cross-portfolio conflict window active) or the model layer (relationship risk score above threshold) that drove the outcome · not a combined black-box decision.
Conflict resolution · explicit, approved, and logged
When the rule layer produces an "eligible" signal but the model layer produces a "suppress" signal · or vice versa · the conflict resolution logic must be explicitly defined in the agent charter, approved by second line, and logged in every decision where the conflict occurs. "In cases of conflict between the eligibility rule set and the relationship risk model, the risk model takes precedence when its score exceeds [threshold]." This is a governance decision requiring named sign-off · it cannot be an engineering default buried in code.
Human escalation for novel decision patterns
Hybrid agents encounter combinations of rule and model signals not seen during development. When the model confidence score is below a defined threshold AND the rule layer produces no clear precedent (the decision falls in a gap between defined rules), the decision must escalate to human review rather than defaulting to either layer. The governance framework must define what constitutes a "gap between rules" in operationally specific terms · not just conceptually · and name the escalation path for each agent.
Proportionate validation for each layer
The rule layer of a hybrid agent requires the same change control as a pure rule-based agent. The model layer requires the same validation regime as a pure model-based agent. Both regimes must be maintained concurrently. The temptation to validate only the model layer (because it feels like the more technical component) and treat the rule layer informally is a common governance gap · particularly because rule layer changes can systematically override model recommendations without appearing in model performance metrics.
The governance principle for hybrid agents: trace every decision back to the layer that drove it. Hybrid agents are hardest to govern because accountability can diffuse · "the model said one thing but the rule said another, so it's unclear whose decision this was." Eliminate that ambiguity with explicit, approved, conflict resolution logic that produces a clear audit trail for every decision, regardless of how it was resolved.
Model Risk Advisory
Validate your explainability architecture against SR 11-7 and GDPR Art.22 requirements
Chapter 14 · Three Lines of Defence
Governance ownership · who is responsible for what
Every governance framework requires named ownership at each line. Agentic AI does not change this model · it makes the ownership mapping more critical, because agents act autonomously and decisions accumulate at a volume that no single individual can review manually.
First line
Business ownership
Marketing Ops · CRM · Product teams
- Define and own each agent's stated objective · what it is trying to achieve and within which constraints
- Monitor the daily operational dashboard: contact volume, policy enforcement rate, no-action rate, channel routing distribution
- Approve all campaign-level overrides of agent routing decisions, with documented justification
- Report anomalies to second line within 24 hours of detection · not after investigation is complete
- Submit all agent logic change requests to second line for review before implementation
- Conduct quarterly business performance review of each agent against its stated objectives
- Maintain the agent charter as a live document, updated at every material change
Second line
Risk and compliance
Model Risk · Compliance · Legal
- Approve the agent governance framework · the operating constraints within which each agent may act
- Own the model inventory: every agent classified, risk-tiered, and assigned a review frequency
- Review and approve all logic changes before production deployment · no emergency bypasses
- Conduct independent weekly sampling of audit logs · random sample of decisions per agent
- Own escalation resolution: when first line escalates an anomaly, second line determines the institutional response
- Produce the regulatory response pack on demand within 24 hours: log extracts, agent documentation, governance evidence
- Chair the monthly AI governance committee and maintain the governance artefact register
Third line
Internal audit
Independent assurance function
- Annual deep-dive audit of each agent's governance framework · does actual operational practice match documented design?
- Backtesting audit: select a stratified sample of historical decisions and verify each was consistent with policy as it stood at the time
- Audit the audit trail itself: verify immutability, completeness, access control logs, and retention compliance
- Test the escalation protocol: were escalations acted on within SLA? Were overrides documented and justified?
- Issue formal findings rated by severity with a required management response and remediation timeline
- Report findings to the Audit Committee and, where material, to the Board Risk Committee
Governance artefacts · who produces, who approves
Agent charter
One document per agent: stated objective, permitted autonomous decisions, mandatory escalation triggers, named human owners, operational KPIs, and suspension criteria. The charter is the single source of truth for what the agent is allowed to do. It is not a technical document · it is a governance document written in plain language that a board member could read and understand.
First line produces · Second line approves · Board Risk Committee receives annual summary
Model risk assessment
Required for every model-influenced agent before first production deployment. Documents: model purpose and methodology, training data and its known limitations, independent validation results and findings, ongoing monitoring plan, and identified residual risks. Updated at every major version change. Classified as a Tier 1 or Tier 2 model risk document under the institution's model risk policy.
Model Risk team produces · Chief Risk Officer approves · External audit receives on request
Change log
Every change to agent logic · however incremental · documented with: what changed (specific rule, threshold, or model parameter), why the change was made, who requested it, who reviewed and approved it, what testing was conducted, and the exact date it became effective in production. The change log is a continuous governance artefact, not a project document. It closes when the agent is decommissioned.
Technology produces · Second line countersigns · Internal audit reviews annually
Monthly governance pack
A structured monthly summary for each agent: decision volume by type, escalation rate and resolution outcomes, override rate with justification themes, contact policy enforcement rate (must be zero breaches for the guardian), model performance metrics vs. validation baseline, anomalies detected in the month, and any open remediation actions from prior periods. The standing agenda for the AI Governance Committee.
First line assembles · Second line presents · AI Governance Committee receives and challenges
Governance Design
Define the AI Governance Committee structure and operating cadence for your institution
Chapter 15 · Escalation Protocols
What forces a human into the loop
The escalation protocol is the operational heart of the governance framework. It defines the conditions under which the institution's stated preference for automation is overridden by its obligation to human oversight · and the precise path that override follows.
Immediate · halt operations and escalate now
High · escalate within 1 hour
Standard · review within 24 hours
Confirmed contact policy breach · customers already overcommunicated
Halt all outbound campaign execution immediately · do not wait to investigate the cause. Identify and enumerate all affected customers within 2 hours. Notify Risk and Compliance and Legal. Assess whether the overcommunication constitutes a reportable breach under relevant regulatory obligations. Campaigns do not resume until root cause is identified, remediated, and signed off by second line. The Policy Guardian agent is reviewed and, if the breach resulted from a system bypass, suspended pending investigation.
→ Chief Risk Officer · Head of Compliance · Marketing Director · General Counsel
Audit log store shows evidence of tampering, deletion, or unexplained gap
Suspend all agents immediately and preserve the log store in its current state · do not attempt repair or reconstruction. This is a potential regulatory disclosure event. Engage Internal Audit, Legal, and IT Security concurrently. The agents cannot resume until log store integrity is independently verified and the technical controls preventing future tampering are strengthened and second-line certified.
→ Head of Internal Audit · General Counsel · CTO · Chief Risk Officer
Any agent making decisions outside its documented charter scope
Suspend the specific agent immediately. Review all decisions made in the preceding 72 hours for out-of-scope actions. Determine whether any customer was materially affected by an out-of-scope decision and whether complaint or remediation obligations arise. Escalate to the AI Governance Committee. The agent cannot resume without a formal root cause review, charter amendment, and second-line sign-off. If the out-of-scope behaviour arose from a code change, treat as a change management failure and engage IT Security.
→ Head of Model Risk · IT Security · Business Owner · AI Governance Committee
Contact volume spike exceeding 3× campaign baseline with no corresponding activation event
The Health Monitor agent pauses the suspect campaign automatically. First line conducts an investigation within 30 minutes. If no legitimate cause is identified within 60 minutes, second line is notified and the campaign remains paused. The investigation must identify the root cause before the campaign resumes · even if the pause creates a commercial opportunity cost. "We couldn't find a reason but it seems fine now" is not a sufficient conclusion.
→ Marketing Ops on-call · Head of CRM · Second-line Duty Officer
Journey Orchestration agent blocks a campaign across 10,000+ customers simultaneously
At this scale, the agent's cross-portfolio conflict detection may be correctly identifying a genuine systemic issue · or it may be a false positive arising from a data quality problem in one of the portfolio signals it monitors. Human review is mandatory before any override. The agent's reasoning must be retrieved, the cross-portfolio signal reviewed against current portfolio data, and the decision reviewed by both the business owner and second line before the block is released or confirmed.
→ Head of Marketing · Head of CRM · Product Risk · Model Risk
Channel selection model confidence score below threshold on more than 5% of decisions in a single day
The model is operating in customer behaviour territory outside its training distribution. Decisions continue but are tagged for daily sampling review by the model risk team. Second line is notified. A formal re-validation is scheduled within 30 days · or immediately if performance degradation is confirmed through response rate monitoring. The model is not suspended at this trigger point unless performance falls below the defined minimum threshold, at which point the escalation severity increases to immediate.
→ Model Risk Team · Head of Analytics · Second-line Duty Officer
Customer complaint directly referencing an automated contact decision
Retrieve the decision record for the customer and date referenced in the complaint within 2 hours of receipt. Generate the explainability text from the primary_reason_code. Assess whether the decision was correct under policy at the time · not under current policy, which may have changed. If the decision was in error: identify all customers affected by the same error pattern, escalate to second line, and initiate remediation within the standard complaints SLA. Document the full decision record in the complaints management system, linked by decision_id.
→ Customer Relations · Compliance · Business Owner
No-action rate exceeds 15% for any agent in any rolling 7-day window
More than 15% of customers entering the decisioning pipeline are receiving no recommended action · a strong signal of data quality degradation, rule over-tightening, or a field mapping failure. Root cause analysis is required within 24 hours. The Data Field Prioritisation agent is alerted to re-score the most likely culprit fields. Marketing Ops receives a same-day notification so campaign delivery expectations can be managed. The 15% threshold itself must be reviewed quarterly and adjusted as the platform matures.
→ Analytics Team · Data Engineering · Marketing Ops · Head of CRM
Any agent's monthly governance pack shows a KPI outside the defined operating range for two consecutive months
A single month outside operating range may be an anomaly. Two consecutive months is a trend · the agent is not performing as governed, and the governance framework has not corrected it. The AI Governance Committee convenes an extraordinary session within 10 business days. The relevant business owner prepares a root cause analysis and remediation plan. If the KPI is contact policy compliance and the value is anything other than 100%, the severity escalates to immediate.
→ AI Governance Committee · Second-line Chair · Relevant Business Owner
The override doctrine: Any human override of an agent decision must be treated with the same rigour as the original decision. The override record must capture: the named individual who overrode (not a role, a person), their stated justification in plain language, the time elapsed between the agent decision and the override, and the subsequent outcome. An undocumented override is a governance failure · it suggests the agent is being circumvented rather than governed. A pattern of overrides in the same direction by the same individual must be reviewed by second line: it may indicate that the agent logic needs adjustment, or it may indicate that governance is being systematically bypassed.
Closing principle · governance as competitive advantage
In a regulated financial institution, the quality of the governance layer is not a constraint on the speed of agentic deployment. It is the licence to operate at speed.
Institutions that invest in governance infrastructure first can deploy and expand agentic capability with confidence. Those that deploy first and govern later will face a harder conversation · with regulators, with internal audit, and with customers · when the first thing goes wrong. The architecture described in this dossier is designed to make "nothing went wrong, and here is the evidence" the default answer.
Complete the engagement
This dossier · diagnostic, architecture, agentic design, and governance framework · provides the complete strategic foundation. The next step is a structured working session with your Technology, Risk, and Marketing leadership to sequence the implementation against your institutional constraints.
Strategic Transformation Dossier · Global Financial Institution · Tibco Decisioning Engine
Confidential · For Authorised Distribution Only