Table of Contents
Summarize and analyze this article with
Chat GPT
Perplexity
Grok
Google AI
Claude
Why most 'AI-ready' platforms aren't
The four layers of an AI-ready banking platform
Retire the legacy core in a single program and stand up a modern replacement. Highest velocity to target state, highest disruption risk, and the most concentrated dependency on the new vendor’s success. Works at very small institutions where the legacy estate is tractable, or at well-capitalized institutions with strong program discipline.
2. Coexistence (parallel run)
3. Hollow-out (strangler pattern)
Keep the legacy core as system-of-record for ledger continuity and move capabilities customer experience, analytics, AI/ML, new products to a modern data and services layer around it. Lowest disruption to ledger and reporting, requires the strongest data and integration discipline. Often the right pattern when the legacy core is stable but constraining innovation.
A decision matrix for choosing the pattern
| Layer | What it does | Decision |
|---|---|---|
| 1 — Lakehouse & catalog | Storage, compute, query; metadata | Buy — commodity |
| 2 — Governed data foundation | MDM, ownership, quality rules, lineage | Build / partner — bank-specific |
| 3 — Feature store & model platform | Reusable features; training/inference | Buy or build, depending on AI volume |
| 4 — Governance overlay | Inventory, risk-tiering, validation, monitoring | Build / partner — required for SR 26-2 |
Most disappointment in this category comes from buying layer 1, getting a demo of layers 3–4, and assuming layer 2 exists. It rarely does at the depth AI use cases require. Layer 2 is the deciding factor and the largest first-year investment.
The 10-criterion vendor evaluation scorecard
| # | Criterion | What ‘good’ looks like |
|---|---|---|
| 1 | Demonstrated lineage on YOUR data | End-to-end lineage rebuilt from your sources, not the demo |
| 2 | Entity resolution support | Strong identity unification or partner integration |
| 3 | MDM depth | Real master-data discipline, not just a label on a catalog |
| 4 | Feature store maturity | Versioned, reusable, with governance metadata |
| 5 | Model & AI inventory | Required for SR 26-2 readiness; should be a deliverable |
| 6 | Explainability for credit AI | Adverse-action reasons under CFPB Circular 2022-03 |
| 7 | GenAI / agentic governance | Concrete controls for the SR 26-2 carve-out |
| 8 | Examiner-ready evidence | Lineage and audit trail as a by-product |
| 9 | Integration cost transparency | Specific number for layer 2 work, not a percentage |
| 10 | Banking references | Peer banks; closed examiner findings under NDA |
Nine hidden costs to interrogate before you sign
- Source profiling and data quality remediation.
- Entity resolution across customer, account, transaction, and product domains.
- MDM design, deployment, and stewardship.
- Lineage capture for every critical data flow.
- Reporting rebuild and parallel-run reconciliation.
- Feature store engineering and feature governance.
- Model inventory build-out and risk-tiering.
- Validation workflows and monitoring instrumentation.
- The three-year run-rate to keep all of the above examiner-ready.
Governance criteria tied to current supervisory expectations
A platform that does not support these is not AI-ready for a U.S. bank, whatever the marketing claims.
- Model & AI inventory — SR 26-2 fluent, including the GenAI/agentic carve-out.
- Risk-tiering by impact — customer impact, regulatory exposure, decision autonomy, data sensitivity.
- Validation & monitoring — proportional to risk, with drift detection.
- Explainability for credit AI — principal adverse-action reasons under CFPB Circular 2022-03.
- Vendor & third-party model oversight — documentation, validation evidence, exit options.
- Examiner-ready evidence — produced as a by-product, answerable on demand.
Build, buy, partner — per layer (not per program)
- Buy the lakehouse, the catalog, the cloud platform. Mature markets.
- Build / partner for MDM, lineage, quality rules, entity resolution, reporting rebuilds, and the governance overlay.
- Hybrid for the feature store — buy if AI volume is high, build if it is concentrated in a few use cases.
How PiTech approaches AI-ready data platforms
PiTech is a practical implementation partner for regulated U.S. banks. Engagements are scoped layer by layer: the lakehouse and catalog are typically bought, the governed foundation and the governance overlay are built with senior practitioners, and the feature store and model platform are sized to the bank’s AI roadmap. Reference outcome: at an anonymized top-25 US bank, governed-data-first work contributed to a 68% reduction in BSA/AML false positives and a 43% reduction in compliance overhead proof that the platform’s value follows the data layer.
Frequently Asked Questions (FAQs)
What is an AI-ready banking data platform?
An AI-ready banking data platform is the combination of a lakehouse and catalog (usually bought), a governed data foundation (MDM, ownership, quality rules, lineage usually built or partnered for), a feature store and model platform, and the governance overlay that SR 26-2 expects (inventory, risk-tiering, validation, monitoring). ‘AI-ready’ describes the condition where new AI use cases can be onboarded with predictable governance and quality, not a product label.
Should a bank build or buy its data platform?
Decide per layer. Buy the lakehouse, catalog, and cloud platform — mature markets with little advantage in building. Build, or partner for, MDM, lineage, quality rules, entity resolution, reporting rebuilds, and the governance overlay; these are bank-specific and decide whether the platform actually serves AI. The feature store is hybrid: buy if AI volume is high, build if use cases are concentrated.
How do you evaluate banking data platform vendors?
Score every option on demonstrated lineage on your data (not the demo), entity resolution support, MDM depth, feature store maturity, model and AI inventory as a deliverable, explainability for credit AI under CFPB Circular 2022-03, GenAI/agentic controls for the SR 26-2 carve-out, examiner-ready evidence, transparent integration cost (specific number not percentage), and banking references with closed examiner findings.
Why do most bank AI pilots fail to reach production?
Most pilots fail because the data underneath them is ungoverned. The model can be excellent and the platform demo can be flawless, but ungoverned data means each use case requires bespoke heroics to onboard, and onboarding cost scales linearly with use cases. Roughly 78–88% of bank AI pilots stall for this reason. Govern the data layer first and onboarding cost compounds favorably.
What does an AI-ready platform actually cost?
Model TCO in four buckets: lakehouse and catalog licensing (usually smallest), the governed data foundation (largest first-year cost entity resolution, MDM, lineage, quality remediation), feature store and model platform, and the three-year run-rate to keep everything examiner-ready. The governed foundation is consistently the bucket vendors exclude from their quotes; get a specific dollar number for it before signing, not a percentage.
How does SR 26-2 affect data platform buying?
SR 26-2 (April 2026) raised the bar for model and AI oversight that runs on the data the platform serves. Any platform you buy must support a defensible model and AI inventory, risk-tiering by impact, validation workflows, monitoring, and third-party model oversight. The GenAI and agentic AI carve-out means the bank must build controls the supervisory letter does not specify the platform should not block that work.
What is a feature store and does a bank need one?
A feature store is a versioned, governed library of model-ready features (e.g., customer risk score components, transaction velocity features) that can be reused across models. Banks with one or two AI use cases may not need a dedicated feature store; banks with a growing AI portfolio almost certainly do, because the alternative is each model re-engineering the same features inconsistently. Feature governance is part of the SR 26-2 readiness footprint.
How is explainability handled in an AI-ready platform?
Explainability must connect model outputs, input features, decision policy, and for credit decisions the principal adverse-action reasons required under CFPB Circular 2022-03. The platform should make this connection testable and documented, not generated retroactively. A platform that can serve a feature to a model but cannot explain which features drove a particular decision is not deployable for credit AI in a U.S. bank.
How long until a bank's data platform is 'AI-ready'?
A first defensible AI-ready domain is achievable in about 90 days: 30 days to scope, govern, and inventory; 30 days to instrument lineage, MDM, and quality on one critical domain; 30 days to onboard a first model with explainability and monitoring. Full-estate readiness is multi-year, but the program needs visible AI-ready wins early to justify continued investment. Govern the data domain that drives your highest-leverage use case first.
What metrics show the data platform is paying off?
Track governed-data coverage percentage by critical domain, AI use cases in production versus pilot, time-to-onboard a new model, examiner findings closed as a result of the program, and compliance overhead trend. Compliance overhead is the most underrated metric here — PiTech engagements have shown reductions of 40%+ on the back of governed-data-first work. ‘Models deployed’ and ‘features published’ are activity metrics that say little about value.