Hybrid cloud CMDB for Charlotte banking: permanent coexistence on a vendor-gone core
Truist Financial’s core deposits system runs on a COBOL platform built decades ago by a vendor that no longer exists. There’s no one left to call when something breaks. That system talks to 180 other applications across the bank. Truist’s own technology leadership has said publicly it will run in a dual-core environment, the old mainframe alongside new cloud-native pieces, for the foreseeable future — not as a temporary bridge, but as the plan. That plan is the reason Charlotte needs a hybrid cloud CMDB for Charlotte banking: a single inventory that treats the mainframe core and everything wired into it as permanent, not a project with a finish line.
That plan is active right now. In March 2026, Truist and Plaid announced an expanded open banking data-access agreement, layering modern account-linking and fraud-signal APIs on top of the same core. The bank is currently hiring ServiceNow developers to build out its IT service management catalog, and running infrastructure modernization work through Accenture and Deloitte. Every one of those efforts adds another system that has to coexist with a mainframe nobody can call the manufacturer about.
A configuration management database (CMDB) answers one question through all of this: what is actually running, old and new, and how each piece depends on the others. Truist has been explicit that this isn’t a phase with an end date — it’s the operating model, and an inventory built for a one-time migration won’t hold up against it.
The banking center this is actually about
Charlotte is not a side market for US banking technology. It is the nation’s second-largest banking center, home to Bank of America headquarters, Truist headquarters, major Wells Fargo East Coast operations, and a dense stack of fintech and payments employers.
EDPNC frames North Carolina’s fintech and payments concentration around that hub. Regional coverage such as QNotes puts Charlotte metro financial services employment above 104,000 roles, with growth that has outpaced many peer metros. Charlotte Regional Business Alliance tracks the same hub story: large balance sheets, large operations centers, and continuous platform change in a few square miles of corporate IT.
When several top-tier institutions modernize cores in the same city at once, inventory failure modes stop being one bank’s private problem.
What a hybrid cloud CMDB actually has to track here
A CMDB is the system of record for configuration items: the servers, mainframe LPARs, middleware, APIs, cloud accounts, SaaS tenants, and application objects operations needs to change safely. A configuration item is anything that can break a deposit path, a card authorization, a fraud signal, or a customer channel when it is wrong, missing, or unowned.
In Charlotte dual-core banking, the hard objects are specific. The COBOL deposits core is a configuration item even when the original vendor is gone. Each of the roughly 180 application integrations Jay Poole described for Truist is a relationship the CMDB must hold, not a footnote in a project deck. LightStream-style modern deposit pilots, open banking connectors, ITSM catalog modules, and consultant-delivered infrastructure packages are also configuration items the moment they touch production paths.
Hybrid cloud here does not mean “cloud only after cutover.” It means mainframe estate and cloud-native estate must live in one continuously updated inventory while both remain authoritative for different slices of the book of business. Migration-era CMDBs that assume a finish line misread the operating model.
Where it actually breaks, with evidence
Truist’s technology leadership put the failure pattern on the record. At American Banker’s Digital Banking conference, Jay Poole described a decades-old COBOL deposits core sold by a company that is no longer in business. He said the core is integrated with 180 other applications, with dual-core operation planned for the foreseeable future rather than a big-bang replacement. Yahoo Finance carried the same panel reporting, including Deloitte’s Gys Hyman on the cost and complexity of “awesome coexistence.” Poole said he did not know whether full migration would take three years, five years, or ten years.
That is not an outlier story. The Federal Reserve Bank of Kansas City briefing on core modernization cites Accenture research that more than 90 percent of retail banks still run on legacy core systems. Virima’s ITIL Change Management and CMDB Accuracy: Why One Depends on the Other covers how discovery-fed inventories close that gap.
When the manufacturer is gone, institutional memory becomes the only vendor manual. If that memory never enters a governed CMDB, every new API and catalog item attaches to a core nobody can fully describe.
What is dual-core banking modernization?
Dual-core modernization runs a legacy deposits or lending core beside a newer cloud-native core for an extended period, often years, instead of a single cutover weekend. New products and integrations attach to both layers, so inventory and dependency maps must treat coexistence as the steady state, not a temporary bridge.
Why Charlotte’s concentration makes this worse
Three large institutions running mainframe-era cores within the same metro compound the same shortages. COBOL engineers, mainframe operators, and integration specialists are a shared labor market. When Bank of America, Truist, Wells Fargo East Coast shops, and regional players all pursue coexistence strategies, staffing for accurate discovery and relationship maintenance gets bid up at once.
Third-party burden stacks the same way. Open banking partners, core processors, card networks, fraud vendors, and systems integrators such as Accenture and Deloitte appear across multiple Charlotte employers, so a weak inventory at one institution creates partner friction for teams that share the same API and consulting networks. Concentration also raises the cost of being wrong — a deposits outage, a bad change, or a PCI scope miss in this hub reaches customer trust and regulator attention faster than the same gap would in a thinner market.
What’s actively expanding on top of the old core right now
On March 12, 2026, Truist announced an expanded open banking data-access agreement with Plaid, also carried on PR Newswire. Account-linking and fraud-signal paths sit on top of the same deposit franchise the COBOL core still anchors. Those connectors are new configuration items and new trust boundaries, not marketing side notes.
At the same time, Charlotte banking IT organizations keep staffing ServiceNow catalog and workflow work and continue infrastructure modernization programs with large integrators. Each catalog item, automation, and landing zone is another object that must reconcile to mainframe and midrange reality. The CMDB cannot treat Plaid-class partnerships or ITSM expansion as a future phase. They land while the dual-core plan is already the stated model.
See what trusted runtime truth requires when legacy cores and new APIs share production indefinitely.
Charlotte banks keep adding open banking APIs and cloud services on cores no vendor still supports. Map mainframe, midrange, and cloud dependencies in one inventory before the next integration lands blind.
What breaks first when the inventory can’t keep pace
Change risk breaks first. With 180 known integrations on a deposits core, a “simple” catalog change or API enablement can touch batch windows, online banking, fraud scoring, and partner feeds. Without current relationships, change impact analysis becomes a meeting, not a map.
Incident scoping breaks next. When dual-core paths disagree, responders need to know which core owns which product slice, which middleware still speaks to COBOL, and which cloud service just joined the chain. Minutes spent rebuilding that picture are minutes customers wait on balances and payments.
PCI DSS pressure lands on the same gap. Cardholder data environments and connected systems must be identified, inventoried, and kept current. Open banking connectors, fraud APIs, and hybrid paths expand how data moves between mainframe records and modern services. If discovery cannot show what stores, processes, or transmits account and card-related data across both cores, scope charts drift.
Assessors ask for populations. Operations answers with last quarter’s spreadsheet. That is how dual-core banking turns an inventory lag into a control finding.
Virima’s broader PCI DSS guidance starts from the same premise: you cannot protect or evidence what you cannot name.
Why does PCI DSS need a hybrid cloud CMDB in banking?
PCI DSS expects a current inventory of systems that store, process, or transmit cardholder data and of systems connected to that environment. In dual-core banks, those paths cross mainframe deposits cores, middleware, cloud services, and open banking APIs, so separate legacy and cloud lists leave scope holes assessors will test.
What accurate visibility actually looks like during permanent coexistence
Accurate visibility treats the mainframe estate and the cloud-native layer as one inventory refreshed on high-frequency scheduled discovery cycles, not two binders owned by two towers. IT discovery has to reach LPARs, distributed servers, containers, cloud accounts, and the integration endpoints that stitch them together.
Dependency mapping has to assume an open-ended integration count. Poole’s 180 figure was a baseline, not a ceiling — Plaid-style partnerships and continuous ITSM catalog work keep adding edges. Once teams define deposit, lending, payments, and digital channel services, service mapping can show blast radius across both cores instead of stopping at the data center wall.
Ownership has to survive vendor disappearance. When no manufacturer remains, the bank’s CMDB, runbooks, and CI owners are the surviving source of truth for what the core still touches. Snapshot projects fail here because the environment never returns to a quiet steady state long enough for a one-time census to stay true.
Where a platform fits
Platforms that combine multi-source discovery, a governed CMDB, and service mapping after service definitions are supplied turn that model into daily operations. Virima discovers and reconciles IT and cloud assets on scheduled discovery cycles, maintains configuration item relationships, and builds ViVID™ service maps once teams define the services that matter. That means mainframe-adjacent infrastructure, midrange systems, and cloud workloads show up as one owned inventory. Integrations with ITSM platforms such as ServiceNow, Jira Service Management, Ivanti, HaloITSM, Xurrent, and Hornbill keep that inventory inside change and incident workflows through a single integrations hub.
The platform job is not a prettier diagram of last year’s core. It is a runtime picture risk, operations, and technology can share while dual-core remains the plan.
Schedule a demo to map dual-core banking dependencies before the next API lands.
When the vendor is gone, the inventory is the manual
A mission-critical deposits system with no manufacturer left to call only has one remaining complete story of what it touches: the bank’s own asset and configuration record. Charlotte’s banking hub will keep layering open banking, cloud services, and catalog automation onto cores like that for years.
If that record stays split between mainframe tribal knowledge and cloud project trackers, coexistence becomes permanent risk. If it stays current across both layers, the bank can change, evidence PCI scope, and recover without dialing a vendor that no longer exists.
Request a demo and walk mainframe-to-cloud ownership against a current hybrid inventory.
Frequently Asked Questions
What did Truist say about dual-core deposits modernization?
Truist technology leadership described a decades-old COBOL deposits core from a vendor no longer in business, integrated with about 180 applications, and planned dual-core operation with newer architecture for the foreseeable future instead of a big-bang cutover.
Why is Charlotte a critical market for hybrid cloud CMDB work?
Charlotte is the second-largest US banking center, with Bank of America, Truist, major Wells Fargo operations, and more than 100,000 financial services jobs. Several large institutions pursue mainframe and cloud coexistence in the same labor and vendor market at once.
How do open banking deals change CMDB requirements?
Agreements such as Truist’s March 2026 expanded Plaid data-access partnership add account-linking and fraud-signal APIs on top of existing deposit cores. Those connectors become configuration items and trust boundaries the inventory must absorb while legacy platforms still run.
Where does PCI DSS show up in dual-core inventory gaps?
PCI DSS needs a defensible inventory of cardholder data systems and connected components. When deposit data, payment paths, and partner APIs span mainframe and cloud layers, incomplete hybrid discovery leaves scope charts and evidence packs incomplete.
How does Virima support banks in permanent coexistence?
Virima runs scheduled discovery across IT and cloud environments, reconciles configuration items into a governed CMDB, and builds ViVID™ service maps after teams define services. That gives operations and risk a shared view of legacy and modern dependencies without waiting for a final cutover date.
Does a hybrid cloud CMDB replace ServiceNow or other ITSM tools banks already use?
No. Virima’s CMDB and discovery layer feeds configuration items and dependency data into ITSM platforms such as ServiceNow, Jira Service Management, Ivanti, HaloITSM, Xurrent, and Hornbill rather than replacing them, so change and incident workflows stay inside the tools teams already run.
