Consumer directed benefits organizations manage processes that are both highly transactional and highly personal. Employers expect efficient onboarding. Participants expect timely access to accounts and cards. Operations teams need accurate information to move across systems without creating delays or errors.
Yet many of the workflows behind those experiences still depend on terminal-based interfaces, manual data entry, batch files, scripts, and limited integration. In organizations using platforms such as Fiserv PCF or 3270-based processes, employees may still need to move information manually between systems to complete routine account and card operations.
The challenge is not simply that these systems are older. Many continue to perform important core functions reliably. The operational problem appears when the workflows around them have not evolved at the same pace as the business.
Manual Account and Card Processes Add Up
Account creation, account maintenance, card setup, card updates, authorization changes, reconciliation, and participant servicing are recurring processes within consumer directed benefits operations.
When those processes require employees to move between multiple systems, even a straightforward request can involve several actions. Information may need to be entered more than once, verified against another system, checked for completion, and researched when something does not match.
The cost is not limited to the time spent entering data. Manual workflows can also create inconsistent information, rework, longer turnaround times, and additional quality-control steps.
They can also make experienced employees a critical part of the process. When only a small number of people know which screens to navigate, which fields to update, and how to handle exceptions, day-to-day operations can become dependent on individual availability and knowledge.
As more employers, participants, plans, and card programs are added, those same steps repeat at a larger scale.
Terminal-Dependent Workflows Limit Digital Progress
3270 interfaces and other terminal-based environments can continue to support reliable core processing. The limitation appears when surrounding processes must conform to the way that interface was originally designed to be used.
A participant portal may collect a request digitally, but an employee may still need to complete the corresponding transaction manually. An employer onboarding system may capture information online, while operations teams still have to re-enter it into the core environment.
The result is a modern front-end experience that still relies on manual processing behind the scenes.
For organizations trying to expand employer connectivity, participant self-service, or partner integrations, that gap can become an operational constraint.
Batch Timing and Disconnected Systems Can Create Data Gaps
Batch processing remains appropriate for many workloads. The issue arises when an operational process needs information or confirmation sooner than the batch schedule allows.
A participant may update information but not see the change reflected elsewhere until the next file runs. An employer onboarding process may pause while one system waits for a scheduled exchange with another. Service teams may receive questions about transactions that are complete in one application but have not yet appeared in another.
When modern benefits platforms and core card systems operate through separate files, manual updates, or disconnected processes, keeping information synchronized can also become more difficult.
Different applications may temporarily reflect different versions of an account, card status, authorization setting, or participant update. That can create additional reconciliation work and make it harder for employees or customers to know which information is current.
At that point, batch timing and disconnected data flow become more than technical considerations. They can begin to affect service levels, employee workload, and the participant experience.
Why Does Onboarding Become a Bottleneck?
Employer and participant onboarding bring many of these challenges together.
A new employer relationship can involve plans, account types, participants, cards, servicing requirements, and multiple internal systems. If each handoff requires manual entry or a separate file exchange, onboarding speed depends on how quickly employees can move information through each step.
That becomes particularly important as a benefits organization grows. More employers mean more setup work. More participants mean more account and card activity. More partner relationships can create more integration requirements.
If workflow volume increases directly with manual effort, growth can eventually create a staffing problem.
Scaling Should Not Require Proportional Headcount Growth
Manual workflows often scale linearly. More volume requires more employee time.
For consumer directed benefits organizations, new employer onboarding, product expansion, higher service expectations, increasing transaction volumes, and demand for self-service can all place additional pressure on the same operational teams.
The scale of the market makes operational efficiency increasingly important. Devenir reports that HSAs reached 41.7 million accounts and nearly $174 billion in assets at year-end 2025, with the number of accounts growing 6% year over year. As CDB participation continues to grow, workflows that scale directly with manual effort can put additional pressure on operations teams.
Adding staff may relieve that pressure in the short term, but it does not change the structure of the workflow. The same handoffs, duplicate entry, terminal dependency, batch timing, and exception handling remain.
The problem becomes even more difficult when important tasks depend on a small number of employees with specialized knowledge of Fiserv PCF, 3270 screens, configuration steps, or established workarounds. As volume increases, that key-person dependency can become another limit on operational capacity.
Scalability therefore becomes a workflow problem as much as a staffing problem.
Self-Service Depends on What Happens Behind the Portal
Modern self-service requires more than a new user interface.
If participants should be able to update account information, request card-related changes, or view current status information, the digital experience needs a reliable way to interact with the systems that perform those functions.
When the underlying process still requires an employee to navigate a terminal, move data manually, or wait for a scheduled exchange, the portal can only automate part of the experience.
Those expectations extend well beyond the benefits industry. Salesforce research found that 61% of customers would rather use self-service channels for simple issues. For CDB organizations, meeting that expectation requires more than adding a portal. The processes behind it must be able to access and act on core account and card functions without relying on a manual handoff.
For organizations pursuing employer portals, participant applications, partner integrations, or mobile services, improving access to core functions becomes an important part of expanding self-service.
What Are the Signs That a Legacy Workflow Is Holding Operations Back?
The symptoms often appear across several parts of the operation rather than in one isolated process.
Common signs include:
- Manual account and card setup
- Repeated entry of employer or participant information
- Dependence on Fiserv PCF, 3270, or other terminal-based processes
- Batch files that delay updates between systems
- Manual handoffs between teams
- Point-to-point scripts or screen scraping
- Poor synchronization between modern and core systems
- Limited API access to core functions
- Key processes that depend on one or a few experienced employees
- Difficulty expanding employer or participant self-service
- Staffing requirements that rise alongside transaction volume
When several of these conditions exist in the same workflow, the issue is no longer just an inefficient task. It can become a constraint on growth, service levels, operational capacity, and the ability to introduce new digital experiences.
The Real Issue Is Often the Workflow Around the Core
For many consumer directed benefits organizations, the core system itself is not necessarily the problem.
The friction often comes from everything employees have to do around it.
Stable systems can continue performing the transactions and business logic they were built to handle. The opportunity is to improve how those capabilities are accessed and used within employer onboarding, participant services, card operations, and partner connections.
That shifts the modernization discussion toward the workflow itself. Which processes require the most manual effort? Where is information being entered repeatedly? Which steps depend on terminal navigation, disconnected files, or a small number of experienced employees? Which processes are becoming harder to support as volume grows?
Those questions can provide a more practical starting point than beginning with a broad change to the system of record.
Where CDB Workflow Modernization Can Begin
CDB organizations can start with one high-friction account, card, servicing, or onboarding process and examine how work moves through it today.
That means looking at the systems involved, the number of manual steps, repeated entry, file exchanges, exceptions, delays, and the amount of employee effort required to complete the process. From there, organizations can identify where trusted core functions could be easier to access, automate, and reuse while keeping the existing system of record in place.
Adaptigent helps reduce that manual work by using Adaptive Integration Fabric to connect established core applications and transactions to modern workflows through governed APIs and orchestration.
Instead of requiring employees to repeatedly move between systems or navigate terminal-based processes for routine activity, organizations can make approved account, card, and onboarding functions easier for modern applications and workflows to use. The core system continues to perform the business functions it already handles, while Fabric provides a controlled connection to the applications and services around it.
This creates a path from improving one high-friction workflow to building reusable services, improving synchronization between systems, supporting more connected onboarding, and laying the groundwork for future self-service. In the next blog in this series, we’ll go deeper into how governed APIs and workflow orchestration can automate CDB operations and turn established core functions into reusable digital services.
Learn more about Adaptive Integration Fabric