The Data Your Partners Can’t Get from You is Value You Can’t Deliver. Feed Them All, and Never Write Another Extract.
Stop writing an extract for every partner. PropelZ™ feeds every service provider from every system you run with one product, so a new partner is live in days and the backlog stops growing. Watch the webinar here.
Partner data sharing is the work an enterprise does to deliver its own data to the service providers and ISV platforms it runs: pricing, billing, payroll, loyalty, recognition, incentives, fraud. For most enterprises that work is a set of hand-built extract programs, one per provider, and the set grows with every platform the business adopts.
That is the part that belongs on the board agenda. A platform is approved, contracted and paid for, and then it waits. It waits for a data feed that has to be designed, coded, tested and scheduled by the same small team that maintains every other feed the business already has. “We can’t keep up with what our partners need from us” is how that team describes it.
The board sees it differently: approved spend that is not yet delivering, initiatives that slip a quarter at a time, and a growing list of partners whose first experience of working with the company is waiting.
It is not a mainframe problem. It is a partner-count problem, and the count only goes up. PropelZ™ replaces every one of those programs with one product. This post covers why the extract is where initiatives stall, what PropelZ does on your side of the boundary, and the bank that asked its platform provider to fix it.
Why is Partner Data Sharing a Board-Level Problem?
Because the data feed is on the critical path of almost everything the board approves.
- Every new platform waits on it. Pricing, payroll, recognition, loyalty, fraud, incentive compensation: each one is bought to move a business metric, and none of them moves until the feed is built. Time to value for the platform is set by the extract backlog, not by the vendor.
- The team that builds feeds is the smallest one in the company. Tens of extracts are maintained by a handful of people who know the record layouts, many of them near retirement. Every new partner adds to their queue. Every departure takes knowledge with it.
- The cost compounds. Each extract is built once and maintained forever. The total grows in a straight line with the partner count, and the partner count grows every year as more of the business runs on someone else’s platform.
The extract program was a reasonable answer when a company had three partners. It does not scale to thirty, and most large enterprises are already past that.
Why do Enterprises Fall Behind Their Service Providers?
Count the providers that receive your data. Now count the extract jobs behind them. That second number is the problem.
- One program per provider. For most large enterprises the answer is tens of programs, spread across z/OS, IBM i, Linux and Windows, each written to one provider’s spec, each staged, reformatted and shipped by file transfer on a batch schedule. Many were written by people who have since left.
- A project for every change. When a provider changes its spec, the change goes into the backlog behind everything else. It needs a developer and a test cycle before anything moves. When you adopt a new platform, its feed is a new project.
- Monthly when providers want daily. The schedule is set by the team’s capacity, not the provider’s needs. Every provider sees the same delay and blames it on its customer, which is you.
Put numbers on it.
- One enterprise data team told us a single extract typically takes six to eight weeks to build, and the request waits months in a backlog before that clock starts.
- Once built, the extract is brittle: change one field in the source record and someone revisits the program, and the data changes often.
- Then there is the operational layer nobody budgets for. What happens when the job fails on a network glitch or a full table at two in the morning, how it gets fault tolerant, how it moves to another system when one goes down, and how an hourly feed, a daily feed and a monthly feed stay synchronized when a dashboard on the other end is asking what happened in the last ten minutes.
- On the mainframe, there is one more line. Much of the software is metered, so the bill is a function of MIPS.An extract that runs on general-purpose engines does not just cost what it uses; it can drive peak utilization higher and raise the license cost of everything else running at the same time, the database included.
The enterprise pays the provider for the platform, and then pays again, on every run, to feed it.
Partner data sharing today: one hand-built path per provider, rebuilt from scratch for every provider added.
What Does PropelZ Do on the Enterprise Side?
PropelZ is VirtualZ Computing’s patented, no-code data movement and decoding platform. It is used for all partner data sharing — one product replaces the tens of extract programs an enterprise maintains today, and it means no new program is written when the next provider is onboarded. If the platform runs Java it runs PropelZ, so one install covers z/OS, IBM i, Linux, UNIX and Windows, on premises or in any cloud.
- Reads data in place. Copybook-described files, VSAM, sequential files, database tables and delimited files, read where they sit. Nothing is written to disk, nothing is staged.
- Filters before it leaves. Only the data each provider needs leaves your estate.
- Maps once per provider. A new provider is a mapping and a schedule, not a program. A spec change is a mapping edit, not a development project.
- Delivers in one hop. Near-real-time to wherever each provider already looks: SQL, Databricks, a data lake, cloud storage, a file, or any application with an API, whether an HR, ERP, CRM or observability platform. The provider does nothing on its side to receive data the new way.
- Uses what you already have. The COBOL copybook you maintain anyway is the layout; hand it over and you are done. For a Db2 table, not even that: PropelZ asks Db2 for the structure. Add three fields to a VSAM file, update the copybook as you would have regardless, and nothing else changes.
- Fits the jobs you already run. If the data a provider needs is produced by an overnight batch job, add one step to that job. Trigger it from CA 7 or whatever scheduler you run, or from a command when someone needs it now.
- Runs incrementally. Because it is fast, PropelZ can run every ten minutes and send only what changed since the last run, so a feed that was daily because of processing cost starts to look like a real-time feed. Petabytes a minute is not on offer; most real feeds are.
- zIIP-eligible on z/OS. Most of the processing is dispatched on zIIP engines, so you can run all you want without driving software costs up. No zIIP in the configuration? There is guidance for that, or run it on Linux, Windows, or Linux on IBM Z in another LPAR on the same machine.
- Scales to thousands of files. One feed is the simple case. Hand PropelZ an inventory of the files that need to go and it runs them ten, a hundred or a thousand at a time and manages the run; one customer moved hundreds of thousands of files this way.
- Round trips. Send a VSAM file to the cloud, process it there, and bring the result back to a VSAM file on the mainframe. Tapes and other mainframe formats included.
Existing extracts retire one at a time as each provider’s feed moves over. There is no big-bang switch, and the next provider is onboarded on the same product rather than on a new path. That is the difference between a cost that grows with every partner and one that does not.
Partner data sharing with PropelZ: one product for every provider, from every system. Tens of extract programs retired, none written for the next.
Can You Share Data with Providers Without Installing Anything on the Mainframe?
Getting new software into a mainframe production environment means security reviews and change processes, and for some enterprises that is the wait that matters. There is a way to start without it. When your provider runs PropelZ on its own side, you keep sending exactly what you send today, in the format you already produce, and the provider decodes it. Nothing is installed in your estate, and the feed stops being the provider’s problem to negotiate with you.
Running it on your own side is the step up, and it is yours to take when you want it. On your side, PropelZ filters before the data leaves: records with hundreds of fields become records with the handful the provider needs, so your network carries a fraction of the bytes and the provider’s processing time drops by roughly half. It is the same engine and the same mapping in either place, and it comes with a licence that covers every other data movement you need to do, not just the feeds to providers.
What About the Data That Already Lives in a Saas Platform?
For most enterprises the worker, org and customer data providers ask for no longer starts on the mainframe. It starts in a SaaS tenant. The path to a provider is still the old one: pull it out of the tenant into your own systems, reformat it, and send it back out. The data leaves the cloud, lands in your estate and goes straight back out again, and your team is in the middle of every hop.
There are two better answers, and PropelZ is the engine for both.
- Make the tenant a source. Point PropelZ at the tenant as input and at whatever you need as output: a Db2 table, a cloud database, a warehouse, a provider’s API. Your HR or customer data lands in a consumable form, on your side, without a custom integration. It runs the other way too. A legacy HR system as input and the SaaS platform as output makes a migration or a bulk load a mapping rather than a project.
- Get out of the middle. Authorize a provider to pull directly from your tenant under a scope you set: which objects, which fields, for that provider only. You control what each provider sees. You stop building and shipping its feed. You become the manager of the data sharing rather than the one who does it, and the provider’s onboarding drops from weeks to the time it takes you to approve a scope.
That is where PropelZ is going next: connectors that read SaaS tenants directly, whichever platform holds the data. HR, ERP, CRM, finance, ticketing, marketing: any platform with a documented API is a source. The engine, the mapping and the one-hop delivery are the same ones described above.
Why Did a Top-Tier Bank Ask Zafin To Implement PropelZ?
The best example of this so far came from the customer, not the vendor. A top-tier global bank runs its core systems on IBM Z and, like every large enterprise, feeds data to a long list of platform providers. One of them is Zafin, a banking platform provider the bank uses for pricing and billing.
The bank did not want to keep building and maintaining extracts for Zafin. It asked Zafin to implement PropelZ to improve the way the two shared data, and introduced Zafin to VirtualZ to make it happen. Zafin built PropelZ into its platform to decode what the bank sends as-is. That solution is in production at the bank today, proven in production for throughput across z/OS formats, and it removed the intermediate data-handling layers that used to sit between the bank’s systems and the platform.
Shahir Daya, Zafin’s Chief Product and Technology Officer: “We’ve increased throughput, reduced unnecessary processing layers, and improved operational efficiency.”
You do not have to wait for your providers to solve this. The same engine that decodes data on the provider’s side sends it from yours, and running PropelZ on your own estate takes the extract problem off your team for every provider at once. When a provider has not solved it on its end, you can do what this bank did and ask.
You can learn more about the Zafin + VirtualZ partnership in the press release and in more detail in our joint Banking AI and Core Data white paper.
What Does Partner Data Sharing Cost, With and Without PropelZ?
You paid for the platform. Then you pay four more times to feed it.
- First the tooling: the integration or ETL software bought before anyone writes a line of code, licensed whether it is used or not.
- Then development, months per extract, by the small team that knows the record layouts.
- Then maintenance, forever, because every extract carried is revisited each time a source field changes.
- Then MIPS, on every run, and the runs go all day: an extract on general-purpose engines does not just cost what it uses, it drives peak utilization and the license cost of everything metered alongside it.
With PropelZ, you pay for one product per platform, each new provider is a mapping, and the processing lands on zIIP engines, so the MIPS line is gone.
There is a fifth cost that never appears on an IT budget: the backlog. Every request still waiting for an extract is a service the business already bought and cannot use. The head of marketing cannot launch the loyalty program. Risk cannot refresh the fraud model. Sales cannot go live on the incentive platform. Those are the costs the sponsor feels, and they are why the request keeps coming back.
Four bills for every hand-built feed, and the backlog behind them, versus PropelZ. Illustrative and indexed; the waits are examples, not measurements. Not a price quote.
The performance side of the cost is less abstract. In one customer benchmark, a large, well-staffed site with licenses for most of the tools in this category built a test of close to ten thousand datasets.
With its incumbent product the job was submitted on Friday and was still running on Monday.
PropelZ ran it in a couple of hours. The 56,000 records per second customers report, mainframe to cloud, works out to roughly six terabytes an hour on a mid-sized cloud instance with modest network bandwidth, and on z/OS that processing lands on zIIP engines rather than the metered ones.
Key Takeaways
- Every platform the business adopts is idle until its data feed exists, and the feed is built by the smallest team in the company. That is a board-level constraint on time to value.
- The extract problem is a partner-count problem, not a mainframe problem. It grows with every platform adopted, on every system you run.
- PropelZ is used for all partner data sharing. One product retires tens or more hand-built extract programs and removes the need to write another as service providers are added.
- Providers do nothing on their side to receive data the new way, and extracts retire one at a time.
- The copybook you already maintain is the layout, and a Db2 table needs no layout at all. Add fields, update the copybook you were updating anyway, and nothing else changes.
- zIIP-eligible on z/OS, or run on Linux, Windows or Linux on IBM Z. Incremental every ten minutes if the provider wants it. Round trips back to VSAM if you need them.
- If installing on the mainframe is the wait, let the provider run PropelZ first and keep sending as-is; run it on your side later to filter before it leaves and halve the provider’s processing.
- Data that lives in a SaaS tenant does not have to come back through your estate. Make the tenant a source, or authorize a provider to pull from it under a scope you set and get out of the middle.
- A top-tier global bank asked its platform provider to implement PropelZ; the result is in production today.
- Cost stays nearly flat as the provider count grows, because each new provider is a mapping, not a program.
What is an Active System of Record?
HR data is uniquely valuable because it is also the data security runs on. A new hire in the HR system of record should mean a mailbox, a directory account, an application login and a badge that works. A termination should mean all of them stop the moment someone presses Enter. Most enterprises cannot do that today. The HR system is in the cloud, the systems that need to know are inside the network, and no enterprise opens its perimeter so a cloud service can push changes in.
So it has to run from the inside, as a pull. Something in your estate takes the change from the system of record and drives every system that depends on it. That is the direction PropelZ points: one engine, inside your environment, reading the record as it changes and delivering it to the systems that need it, so the system of record is active rather than a place your data waits to be copied out of.
Where to Start
Start with an inventory: how many providers receive your data, how many extract jobs sit behind them, and who maintains each one. Then pilot one provider feed and switch off that extract. The rest follow at the pace your team chooses.
Then test it. This is not a six-month proof of concept. If the mainframe queue is the wait, test it off the mainframe first, on any platform you already run, against the same data. You will know what it does for one feed before the next request reaches the top of the backlog.
For the same problem seen from the provider’s side, read our companion blog: ISV Onboarding: From Months to Days with PropelZ™
Frequently Asked Questions
Can you share data with providers without installing anything on the mainframe?
Yes. When your provider runs PropelZ on its own side, you keep sending exactly what you send today, in the format you already produce, and the provider decodes it. Nothing is installed in your estate.
What about the data that already lives in a SaaS platform?
PropelZ can read the SaaS tenant directly as a source, or you can authorize a provider to pull from it under a scope you set — either way, the data stops routing back through your estate on its way to the provider.
Why did a top-tier bank ask Zafin to implement PropelZ?
The bank did not want to keep building and maintaining extracts for Zafin. It asked Zafin to implement PropelZ, and Zafin built it into its platform to decode what the bank sends as-is — removing the intermediate data-handling layers that used to sit between the bank’s systems and the platform.
What does partner data sharing cost, with and without PropelZ?
Without PropelZ, an enterprise pays for extract tooling, development, ongoing maintenance, and mainframe MIPS on every run — plus the backlog cost of every platform still waiting on its feed. With PropelZ, each new provider is a mapping, not a new program, and the processing runs on zIIP engines on z/OS.
What is an active system of record?
A system where a change — like a new hire or a termination in HR — immediately drives every downstream system that depends on it, rather than waiting to be extracted and copied out on a schedule.
Next Steps
- Schedule a PropelZ briefing.
- Watch the webinar here.
- Read the Zafin + VirtualZ press release.
- Read joint Zafin + VirtualZ Banking AI and Core Data white paper.
Learn More
- Visit our Customer Briefing Center.
- Review all VirtualZ Use Cases, Thought Leadership papers, and Solution Briefs.
- Explore our YouTube channel, podcasts, and blog.
- Still have questions? Contact us.