Skip to content
← Selected work

Case study · AI-Assisted BI

Gen-AI Debt Collection POC

The POC demonstrated that personalised messaging is technically feasible in this banking context, but it also surfaced the governance and review work a production version would need: prompt-version control, audit logging of inputs and outputs, segment-level guardrails, and a fallback to templated messaging when model confidence is low.

Banking
  • genai
  • azure-openai
  • poc
  • banking-analytics
Anonymized AI workflow exploration visual with banking data context, Azure OpenAI cues, and review controls.
Anonymized AI workflow exploration frame

Evidence snapshot

Outcome signal
Feasibility demonstrated without overclaiming scale
Demonstrated feasibility of AI-assisted personalized messaging
Focus
POC for personalized messaging
Industry: Banking
My role
POC design and delivery, scope decisions, and honest scoping of the gap between feasibility and production readiness
Tools: Azure OpenAI, Python, Azure Databricks

Summary

The POC demonstrated that personalised messaging is technically feasible in this banking context, but it also surfaced the governance and review work a production version would need: prompt-version control, audit logging of inputs and outputs, segment-level guardrails, and a fallback to templated messaging when model confidence is low.

What needed to change

Debt collection messaging was largely template-driven, which limited how well it could adapt to borrower context across segments. Any AI-assisted approach had to work inside banking governance constraints — limited data movement, strict auditability, and no assumption that model output reaches a customer without human review.

Context and constraints

The POC sat inside a regulated banking environment, so anything promising still had a long path to production. The real question was not "does it work?" but "does it work within the constraints we actually have, and what would it cost to harden?"

  • Manual, non-personalized messaging approach

How the work was handled

Built a POC on Azure OpenAI and banking-domain data, using Python and Azure Databricks for the data preparation layer. Kept the pipeline small enough to reason about end to end: a controlled prompt layer, a segment-aware context window, and an explicit human-review gate before any generated output left the environment.

What changed in practice

The POC demonstrated that personalised messaging is technically feasible in this banking context, but it also surfaced the governance and review work a production version would need: prompt-version control, audit logging of inputs and outputs, segment-level guardrails, and a fallback to templated messaging when model confidence is low.

  • Built a proof of concept using Azure OpenAI and banking data.
  • Explored more personalized debt collection messaging strategies.
  • Presented the work as feasibility exploration rather than production transformation.

Framed as a feasibility POC, not a scaled production transformation. The value of the engagement was a clear, review-ready view of what AI in this context can and cannot responsibly do today.

My role

POC design and delivery, scope decisions, and honest scoping of the gap between feasibility and production readiness

Tools: Azure OpenAI, Python, Azure Databricks

Choices and lessons

  • Used Azure OpenAI and Python in a banking analytics context.
  • Positioned the work as a POC with controlled scope.
  • Focused on personalized messaging strategy exploration.

Implementation detail

What this POC actually proved

Feasibility POCs in regulated environments are worth more when they come back with an honest map of the gap, not a polished demo. The goal here was to test whether a segment-aware prompt could produce usable draft messaging, and to surface the production-readiness cost before anyone committed to scale.

How the workflow was shaped

  • Data preparation ran in Azure Databricks with domain-specific features only — no general customer PII in the prompt.
  • The prompt layer was deliberately small: a controlled system prompt, a segment-aware context window, and a bounded output format.
  • Every generated message passed through a human-review step. Nothing generated was delivered to a customer directly.
  • The prompt layer was isolated from the data layer so each could be audited, versioned, or swapped independently.

What a production version would still need

The POC deliverable included, in writing, what would be required before anything shipped: prompt-version control, audit logging of every input and output, segment-level guardrails, and a fallback to templated messaging whenever the model returned low-confidence output. Naming those requirements explicitly is the point of a feasibility POC.

Highlights

  • Azure OpenAI POC built inside banking governance constraints rather than a sandbox.
  • Human-review gate between generation and any outgoing message — feasibility, not autonomy.
  • Deliverable included an honest production-readiness gap assessment, not just a working demo.
  • Scoped clearly as a POC with specific next-step requirements documented for the team.

Need similar help with reporting, model quality, or BI delivery?

Start with the current constraint, what needs to change, and where delivery risk is showing up now.