In vendor marketing it means almost nothing. It is applied equally to a mainframe core with a REST gateway in front of it and to a genuinely distributed ledger. Four questions separate them: can it scale horizontally without a maintenance window, is the data model accessible to you directly, are upgrades continuous or annual projects, and does it have a real end-of-day batch. The last one is the tell.
Batch is the clearest signal because it is architectural rather than cosmetic. A core built around a nightly cycle has a window during which balances are not authoritative, and no amount of API modernisation removes it. If the answer to “what happens to a payment at 23:58” involves a cut-off, you are looking at a traditional core with a modern facade, which may still be the right choice but should be chosen knowingly.
Horizontal scalability is worth testing instead of accepting. Ask what happens at ten times the demonstrated volume and whether the answer is more instances or a bigger instance. Vertical-only scaling has a ceiling, and you will meet it during the growth you were hoping for.
Data access determines whether you can build anything the vendor did not anticipate. A core that exposes events and gives you direct read access to your own ledger lets you build reporting, analytics and reconciliation on your terms. One that exposes only a fixed API surface means every new requirement becomes a vendor roadmap conversation.
Upgrade cadence reveals the rest. Continuous, backwards-compatible deployment implies an architecture that can tolerate it. An annual upgrade project that requires a testing programme means the vendor's release process is your release process, and your roadmap now contains their calendar.