The Data Your Customers Can’t Get You Is Growth You Can’t Book. Decode It All, and Onboard in Days.
Stop building an intake for every customer. PropelZ™ decodes any layout inside your platform — on whatever platform you run — so onboarding takes days, not months, and the customer installs nothing. Watch the webinar here.
Customer data sharing is the step where an ISV’s platform receives the enterprise data it needs from each customer’s systems. It is also the step that decides when a signed customer becomes a live one. Until the data arrives, nothing the ISV sold can run, and nothing it sold can be billed for in full.
For most ISVs that step is out of their hands. The data sits on IBM Z, on IBM i, on Linux and Windows servers and in SaaS tenants, and getting it out is the customer’s job, done by the customer’s team, on the customer’s schedule. Sales closes in a quarter. Onboarding takes most of a year. The gap between the two is the largest source of unrecognized revenue most ISVs carry, and it is invisible on the pipeline report because every deal in it is already marked won.
PropelZ™ changes who owns the step. Running inside the ISV’s platform on any platform the ISV runs, it decodes whatever the customer sends, in whatever layout the customer already produces. This post covers why the gap exists, why it belongs on the board agenda, what PropelZ does about it, and how Zafin used it to take the problem off every bank it serves. (Read the Zafin press release and white paper.)
Why is Customer Onboarding a Board-Level Problem for an ISV?
Because it sets the ceiling on growth. Three numbers a board already watches all run through the data feed.
- Time to revenue. A customer is booked when it signs and earns its keep when its data flows. Every month in between is a month of contracted value the ISV cannot recognize, support cost it is already paying, and a customer whose first experience of the platform is waiting.
- Capacity to scale. If each new customer needs a one-off intake, the onboarding team grows in step with the customer count. The ISV cannot sign faster than it can build intakes, and it cannot build intakes faster than its customers build extracts.
- Competitive position. In every category, the platform that is easiest to feed wins the deals where the customer’s IT team is the objection. “We don’t have people to send you the data” is the last objection standing in most enterprise sales, and the ISV that removes it closes what the others cannot.
None of these are IT problems. They are the growth plan, and they are gated by something the ISV has historically treated as the customer’s responsibility.
Why Does ISV Onboarding Wait on the Customer?
Three things happen every time an ISV signs a new enterprise customer, and each one adds months.
- The extract sits in someone else’s backlog. The customer’s IT team has to build an extract before anything flows. That work is scheduled by the customer, against every other partner the team serves, and the ISV cannot move it up. Onboarding is measured in months.
- Every customer sends a different layout. A copybook-described EBCDIC file from one, a VSAM export from another, a database dump from a third. The ISV builds a one-off intake for each and carries it for as long as the customer exists. A hundred customers is a hundred intakes.
- The data arrives monthly. Extracts run on a batch schedule set by the customer’s capacity, so the platform runs on last month’s data and the ISV’s roadmap is gated by the oldest part of its customers’ estates.
None of this is the customer’s fault. The same team is serving ten or twenty other providers the same way, one hand-built extract each. Pushing the problem back onto them does not make it go away.
The numbers behind that are worse than most ISVs assume. One enterprise data team told us a single extract typically takes six to eight weeks to build, and that clock starts only when the request reaches the top of a backlog that can run months. The team is rarely well funded, and it is serving every other provider the same way. Then the archaeology begins: much of the data is legacy, produced for generations, and the people who knew why a field holds the value it does are gone. The customer may not know its own data, and it will expect the ISV to help it find out.
Customer onboarding today: wait for the customer’s extract, then build a one-off intake path, rebuilt from scratch for every customer signed.
Do Customers Have to Install Anything to Share Data with an ISV?
No. This is the question an ISV chief technology officer asked us this month, and it is the question every ISV is really asking. With PropelZ inside the ISV’s platform, the customer sends what it already has, in the format it already produces, and installs nothing. The ISV takes it from there.
Who Owns the Metadata, the ISV or the Customer?
Every ISV wants its customers to look the same. Every large customer wants to send what it already sends to everyone else, take it or leave it. The compromise is usually a one-off intake per customer, which is the worst of both.
The way out is to make the layout a declaration rather than a negotiation, and to let either side make it. PropelZ supports both. The customer can say “here is what I am going to send you,” hand over the COBOL copybook it already maintains, and PropelZ reads the data from that. Or the ISV can publish “here is what I need,” and the customer maps to it once. Which one fits depends on the application, but neither requires anyone to write a parser.
One ISV we worked with received input records with hundreds, in some cases thousands, of fields per customer. It needed about fifty. Its answer had been custom filtering software, written again for each customer. With the layout declared once, the fifty fields are selected in a mapping, and the other thousand never have to be understood at all.
How PropelZ Decodes Customer Data Inside the ISV Platform
PropelZ is VirtualZ Computing’s patented, no-code data movement and decoding platform. Installed once, wherever the ISV’s platform already runs, since PropelZ is multiplatform and runs on any system with a Java runtime and in any cloud, it is the one engine for every customer — it turns any customer feed into data the platform can use, retires the one-off intakes the ISV has built so far, and means no new intake is written when the next customer signs.
- Automatic layout discovery. The copybook is the spec. PropelZ reads copybook-described and EBCDIC files, VSAM and sequential exports, database tables and delimited files without a parser written for each customer.
- Declarative mapping, once per customer. Fields are mapped to the platform’s model one time. When a customer moves a field, the fix is a mapping edit, not code.
- Transformation in flight. Map, filter and convert as the data lands, so it arrives in the shape the platform expects.
- Delivery in one hop. Straight into the platform database, warehouse, Databricks or data lake. Nothing is staged, and nothing is cleaned up by hand afterward.
The customer installs nothing and changes nothing. When a customer can send more often, the platform runs on fresher data without anyone on either side writing code.
Customer onboarding with PropelZ: one engine for every customer. One-off intakes retired, none written for the next customer signed.
Where Does PropelZ Run Inside an ISV Platform?
Wherever the platform runs. PropelZ is multiplatform: it runs on z/OS, IBM i, Linux, UNIX, Windows, macOS, VSE, VM and any other environment with a Java runtime, on premises or in any cloud, and no mainframe is required anywhere in the ISV’s estate to process mainframe data. The time in a deployment goes to the ordinary things around it: network access to the targets, digital certificates, the connectivity any new component would need.
How it runs is the ISV’s choice. One banking platform runs PropelZ as a container that starts when a customer feed arrives, does its work and disappears. Multi-tenant platforms decide how to segregate customer data, whether a database per customer, a table per customer or one table with a tenant identifier, and PropelZ lands the data accordingly. If the platform needs the same feed in two places, say a Postgres copy for the application and a Snowflake copy for analytics, it delivers to both.
It is also not all or nothing. Some ISVs use PropelZ for ingestion and transformation only, in front of infrastructure they already have. One asked for the opposite: no transformation at all, bit for bit what was on the original input, because it already had software that understood those records. Both are a configuration, not a project.
What if the Customer’s Data Lives in a SaaS Platform?
Then the customer is doing the work twice. Its worker, org, eligibility or account data starts in a SaaS tenant, gets pulled into the customer’s own systems, reformatted, and sent back out to the ISV. Data goes from the cloud into the enterprise and straight back out again, and the customer’s team is in the middle of every hop.
The better path takes the customer out of the middle. The customer authorizes a feed once, inside the SaaS tenant, and scopes it: which objects, which fields, for which provider. The ISV pulls directly from the tenant on its own schedule and lands the data in its platform, program-ready. The customer stays in the loop where it matters, controlling what each provider can see, and steps out of the loop where it hurts, building and shipping the feed. It becomes the manager of the data sharing rather than the one who does it.
For the ISV this is the same engine and the same mapping, with the tenant as the source instead of a file. That is where PropelZ is going next — connectors that read the customer’s SaaS tenant directly, whichever platform it is. HR, ERP, CRM, finance, ticketing, marketing: any platform with a documented API is a source, and the ones where most inbound worker, org and account data originates come first.
How Did Zafin Use PropelZ to Onboard Bank Customers?
Zafin provides a banking platform used by large banks for pricing, billing and related core functions. Its bank customers hold the source data on IBM Z, and its bank customers fed the platform the usual way: a bank-built extract, staged and reformatted before Zafin could use it.
The change started with a customer request. A top-tier global bank that runs Zafin did not want to keep building extracts for it, so they asked Zafin to implement PropelZ to improve the way the two shared data and introduced Zafin to VirtualZ.
Zafin could have treated that as one bank’s request. Instead, it built PropelZ into its platform to decode mainframe data from bank customers directly, and took the problem off every customer at once.
The flow is simple. The bank sends its data to Zafin. Zafin decodes and processes it with the solution it built on PropelZ. VirtualZ is not in the data path. The result is in production at that bank, proven in production for throughput across z/OS formats, with the intermediate data-handling layers that used to sit between the bank and the platform removed.
Shahir Daya, Zafin’s Chief Product and Technology Officer, describes the outcome: “We’ve increased throughput, reduced unnecessary processing layers, and improved operational efficiency.”
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.
Should the ISV or the Customer Run PropelZ?
Asking a large enterprise to install anything in its mainframe production environment triggers security reviews and change processes that can take longer than the onboarding itself. So the default is that the customer keeps sending exactly what it sends today, and the ISV runs PropelZ on its own side to decode it. Nothing is installed at the customer.
The customer can go a step further when it wants to. Running PropelZ on its own side, it filters the feed before it leaves the estate, sends only the fields the ISV needs instead of every column, and cuts the processing on the ISV’s side by roughly half. It is the same engine and the same mapping in either place. The ISV offers both, the customer picks best performance or least change, and the ISV’s intake is the same either way. Some of that banking platform’s banks are now taking that step.
What Does Customer Onboarding cost, With and Without PropelZ?
The cost of a one-off intake does not stop at go-live. First comes the onboarding wait, months in which the deal is booked but cannot be billed in full. Then the relationship runs, and every feed after that depends on a customer extract the ISV does not control: a late file, a failed batch job, a layout that changed without notice. Each one is an SLA the ISV misses on the customer’s behalf, and each one has a cost of its own: service credits, support load, stale-data errors and, at renewal, a customer whose experience of the platform has been waiting. With PropelZ inside the platform, the customer is live in days and the ISV runs on current data on its own schedule; the customer’s extract is no longer on the critical path for either. Multiply the picture below by every customer signed.
One customer, two years: the onboarding wait and the ongoing service delays with legacy customer extract programs versus PropelZ. Timing of misses is illustrative. Not a price quote.
Throughput is the other half of the cost. Every ISV asks about performance first, and the pattern in deployments has been consistent: ingestion that took hours runs in half the time, and in some cases a tenth. That matters beyond the bill. Terabyte feeds from hundreds of customers over ordinary networks become the ceiling on how far a platform can scale, and one glitch and retransmit turns into a missed SLA. In one customer benchmark, a large and sophisticated site built a test of close to ten thousand datasets; with its incumbent product the job was submitted on Friday and 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.
Key Takeaways
- The gap between signed and live is the largest source of unrecognized revenue most ISVs carry, and it is set by the customer’s data feed.
- ISV onboarding waits on the customer because the extract is the customer’s job. Moving that job to the ISV’s side removes the wait, and the ceiling on growth with it.
- PropelZ is one engine for every customer, on any platform the ISV runs. It retires the one-off intakes built so far and removes the need to write another as customers are signed.
- The customer installs nothing and changes nothing. It sends what it already produces.
- The layout is a declaration, not a negotiation. Either the customer hands over the copybook it already maintains or the ISV publishes what it needs; PropelZ supports both, and nobody writes a parser.
- The customer keeps sending as-is and the ISV decodes it, or the customer runs PropelZ on its own side to filter before it sends and cut the ISV’s processing by roughly half. Same engine, same mapping, the customer’s choice.
- When the customer’s data already lives in a SaaS tenant, the customer can authorize a scoped feed once and let the ISV pull it directly. The customer controls what the ISV sees and stops building the feed.
- Zafin built PropelZ into its banking platform at a customer’s request and now decodes bank data directly, in production at a top-tier global bank.
- One product replaces a one-off intake per customer, so cost stays nearly flat as the customer count grows.
What Happens When Customer Data Sharing Reaches Thousands of Files?
Once the intake is no longer built per customer, the ceiling on how many customers an ISV can onboard moves from the size of its integration team to the size of its sales team. The hundredth customer costs the same to bring live as the tenth: a mapping and a schedule. That is what lets an ISV sell into accounts it used to qualify out, the ones whose IT teams could never get to the extract, and it is what lets onboarding keep pace when the customer count doubles.
The pattern holds for any ISV whose customers keep source-of-truth data in systems they cannot easily get it out of: HR and payroll, loyalty, insurance, incentive compensation, banking. It holds whether that system is a mainframe or a SaaS tenant, and it holds wherever the ISV runs its platform, because PropelZ runs on any platform that runs Java. Some of those customers will go a step further and run PropelZ on their own side, retiring every extract they maintain for every provider at once.
For the same problem seen from the enterprise’s side, read our companion blog: Stop Rebuilding an Extract for Every Customer
Frequently Asked Questions
Do customers have to install anything to share data with an ISV?
No. With PropelZ inside the ISV’s platform, the customer sends what it already has, in the format it already produces, and installs nothing.
Who owns the metadata, the ISV or the customer?
Either can. PropelZ lets the customer hand over the copybook it already maintains, or lets the ISV publish the layout it needs and have the customer map to it once — neither approach requires writing a parser.
Where does PropelZ run inside an ISV platform?
Wherever the platform runs. PropelZ is multiplatform — z/OS, IBM i, Linux, UNIX, Windows, macOS, VSE, VM, or any environment with a Java runtime, on premises or in the cloud — so no mainframe is required anywhere in the ISV’s estate.
What if the customer’s data lives in a SaaS platform?
The customer authorizes a scoped feed once inside the SaaS tenant, and the ISV pulls directly from it on its own schedule — removing the need for the customer to pull the data out, reformat it, and send it back out manually.
Should the ISV or the customer run PropelZ?
By default, the ISV runs PropelZ on its own side to decode whatever the customer already sends, since installing anything in a customer’s mainframe production environment triggers security reviews. Customers who want to filter the feed before it leaves their estate can run PropelZ themselves instead.
How did Zafin use PropelZ to onboard bank customers?
Zafin built PropelZ into its banking platform to decode mainframe data from bank customers directly, at the request of a top-tier global bank, removing the intermediate data-handling layers that used to sit between each bank and the platform.
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.