Jack Henry / SilverLake automation
Xperience banking software, and the work that still happens by hand inside it
Xperience is Jack Henry's unified screen over the SilverLake core. Most guides stop at what it is or how developers wire into the jXchange API. The harder question for an operations lead is simpler: who automates the hundreds of repetitive entries that staff still type into Xperience every week?
Direct answer (verified June 22, 2026)
Xperience is Jack Henry & Associates' modern user-interface framework. It gives bank and credit-union staff one consistent screen across the SilverLake core and Jack Henry's complementary products, with single sign-on handled through the jXchange federated identity service. It is a front end and visual integration layer, not a core in its own right.
Source: Jack Henry developer documentation, Xperience overview.
What Xperience actually is
A community or regional bank running Jack Henry does not run one application. It runs the SilverLake core plus a stack of complementary products: deposits, lending, card processing, bill pay and ACH, real-time payments, and a long tail of third-party modules. Historically each of those had its own look, its own login, and its own quirks.
Xperience is the layer that pulls those together. It gives staff a single, consistent interface and uses jXchange for federated single sign-on, so a teller or back-office clerk moves between the core and the surrounding modules without re-authenticating or re-learning a new screen. Think of it as the cockpit that Jack Henry built over an ecosystem of systems that were never designed to look alike.
Where the API stops and the typing starts
Jack Henry does expose programmatic integration: jXchange and SymXchange let approved partners read and write business data between the core and third-party apps. They are genuinely capable. But there are three things the API path does not solve for an operations team that needs results this quarter.
- Access is gated. Every integration is scoped, approved, and sequenced through Jack Henry and the bank's own roadmap. You do not simply get a key and start automating next week.
- It does not cover every screen. The API surfaces the operations Jack Henry chose to expose. A lot of day-to-day back-office work lives on screens that have no matching endpoint, so a person still keys it in.
- It is moving underneath you. Jack Henry is in the middle of shifting jXchange off its legacy SOAP transport toward REST, so an integration you build against today's contract may need rework on the vendor's timeline, not yours.
None of that is a knock on Jack Henry. It is just the reason a queue of repetitive work keeps landing on a human inside the Xperience UI: new account setup, maintenance changes, exception handling, cross-module reconciliation, document data entry. That queue is the automation target.
Two ways to automate work inside Xperience
The integration route and the UI route are not rivals. They cover different work. Here is where each one fits.
| Feature | jXchange / SymXchange integration | UI-level agent (Mediar) |
|---|---|---|
| Time to a live workflow | Weeks to months: scoping, vendor approval, and a build cycle | Days: watch the workflow once, run it |
| Screen coverage | Only the operations exposed as endpoints | Anything a person can do on the Xperience screen |
| Access requirement | Approved jXchange/SymXchange project and credentials | Runs as the user, on screens staff already use |
| When the UI changes | Unaffected (API contract), but contract itself can migrate | Re-resolves against the accessibility tree, self-heals |
| Best for | High-volume, system-to-system data exchange | The long tail of manual entry the API never reached |
If a workflow is genuinely a bulk system-to-system data sync and you already have jXchange access, use the API. The UI agent earns its keep on everything that fell through that net.
How an agent drives the Xperience screen itself
The mechanism is the part most guides skip, and it is the part that decides whether an automation survives the next release. Mediar does not look at the screen as an image and it does not click recorded coordinates. It reads what the application publishes to the operating system's accessibility APIs, the exact same structured tree a screen reader consumes for a blind user. Every field, label, and button is a named element with a role, not a pixel.
Record once, then execute
Watch the workflow once
A clerk runs the real task in Xperience while the agent observes: which screen, which field, which value, in what order.
Resolve against the accessibility tree
Instead of saving coordinates, the agent records the named elements the Xperience UI exposes to assistive technology, so each step is anchored to a role and label.
Execute on the live screen
On every run the agent finds those elements again and drives them: focus the field, set the value, trigger the action, read the result back.
Self-heal when a release shifts the UI
When Jack Henry moves a control or renames a label, the agent re-resolves against the tree rather than failing on a coordinate that no longer points at anything.
That is the uncopyable detail. The engine that does this is open source: the Terminator SDK on GitHub. A bank's automation team can read exactly how a step is resolved and extend it, instead of trusting a black box. The same approach already drives legacy desktop systems with no usable API, including SAP GUI, mainframe terminals, and other banking cores.
What this changes in practice
The reason this matters is throughput on the work no integration ever picked up. The numbers below are documented Mediar deployments, not projections.
“Bank onboarding that used to take eight weeks to stand up now reaches production in two, because the workflow runs against the screens staff already use instead of waiting on an integration project.”
Documented Mediar bank deployment
Have a Jack Henry workflow stuck in the manual queue?
Bring one repetitive Xperience or SilverLake task to a call and we will scope whether a UI-level agent can run it without a jXchange project.
Xperience banking software: common questions
What is Xperience banking software?
Xperience is Jack Henry & Associates' modern user-interface framework. It gives bank and credit-union staff one consistent screen across the SilverLake core and Jack Henry's complementary products, with single sign-on handled through the jXchange federated identity service. It is a front end and an integration layer, not a core in its own right.
Is Xperience the same thing as SilverLake?
No. SilverLake is the core banking platform that holds accounts, transactions, and posting logic. Xperience is the unified interface and visual integration layer that sits on top of SilverLake and the complementary products around it, so staff move between modules without switching applications.
Does Xperience have an API I can automate against?
Jack Henry exposes jXchange and SymXchange for programmatic integration. They are real and powerful, but access is gated through Jack Henry, every integration is scoped and approved, and they do not cover every screen a back-office clerk touches. Plenty of repetitive Xperience work still happens by a human typing into the UI, which is exactly the gap a UI-level agent fills.
How does Mediar automate Xperience without a jXchange key?
Mediar reads what the Xperience UI exposes through OS-level accessibility APIs, the same interfaces a screen reader uses. It drives the real fields and buttons on the screen, so a workflow can go live without a vendor integration, an API key, or a project on the bank's jXchange roadmap. If the interface labels or layout shift in a Jack Henry release, the agent re-resolves against the accessibility tree instead of breaking on a pixel coordinate.
Is this just screen scraping with brittle coordinates?
No. The whole point of the accessibility-tree approach is that there are no pixel matchers and no recorded coordinates. The agent works from the named, structured elements the application publishes to assistive technology, so a button that moves stays findable by its role and label. That is why these automations self-heal across UI updates where image-matching RPA snaps.
What does it cost compared to traditional RPA?
Mediar is $0.75 per minute of runtime with no per-seat licensing, plus a $10,000 turn-key program fee that converts to usage credits. The documented comparison: an F&B chain that moved off UiPath now runs at roughly 20% of the prior cost, and a bank onboarding workflow went from 8 weeks to 2 weeks to reach production.
Can our own team extend it?
Yes. The execution engine is the open-source Terminator SDK at github.com/mediar-ai/terminator. A bank's automation team or RPA Center of Excellence can build and version custom Xperience workflows in code, while non-developers record runs in the no-code web app.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.