Loading
Open finance, instant payments and partner APIs run on a layer in front of the core you already have. There is no migration programme and no core replacement, so the mandate date stays reachable.
FOUR SYSTEMS · ONE CONSENT
Where it breaks
Open finance, instant payments and ISO 20022 all assume a bank that answers in milliseconds. Most cores were built to answer overnight, and replacing one is a multi-year programme nobody wants to start under a deadline.
Partner APIs carry response-time obligations your core was never designed to meet. Put third-party traffic straight through to it and you put the branch network and the batch window at risk alongside it.
We serve partner reads from projections we maintain, so the core stays off the critical path.
A customer grants access in the app, but the scope lives in one system, the revocation in another, and the access log in a third. When the regulator asks what a third party could see last March, nobody can answer quickly.
One consent lifecycle. We check every access against it and write it to an evidence trail you can export.
Open finance, ISO 20022 migration and reporting changes each get their own build, their own team and their own integration. Three years later there are three platforms and one very tired change board.
One layer serves all of them. The next mandate comes down to a mapping and a policy.
How it works
We authenticate each request, check it against consent, serve it from projections and write it to an evidence trail on the way through.
Systems of record
VKraft layer
Consumers
FAPI 2.0 and OAuth2 for authorisation, ISO 20022 for payments, PayNet Open Finance profiles for data sharing. When a profile version changes, you change a mapping and leave the architecture alone.
The runtime sits on your cloud tenancy, in your data centre, or split across both. Residency and RMiT expectations usually make the decision, and we design to them.
API latency, consent volumes, failed authorisations and partner behaviour all land on one dashboard. We can run it under a support agreement if you would rather not.
Products
finX, MetricMonitor and DwaniAI read the same normalised model and honour the same consent, so a customer is the same customer in all three.
Consent capture, authorisation and data sharing built to the Malaysian Open Finance framework. It sits in front of the core and leaves it untouched.
Explore finX →Payment cutoffs, batch health, API latency and integration pipeline status on one screen, with history an auditor can read.
Explore MetricMonitor →Balances, transfers, product questions and servicing over chat and voice, with authentication before anything sensitive and a handover to an agent when a question needs a person.
Explore DwaniAI →How we work
Third-party traffic reads from projections we maintain and keep current. It never touches the system your branches and ATMs depend on. A partner having a bad day stays the partner's bad day.
A surge from an aggregator cannot slow the branch network, the card switch or the overnight batch.
We scope rate limits per consent, so one misbehaving client gets contained without throttling everyone else.
Whatever we replaced stays configured until you retire it. Reverting inside a change window means flipping a switch. There is nothing to restore.
Recent work
Anonymised at the client's request
A tier-2 bank had an open finance obligation and a core it could not expose directly. The internal debate had stalled between a core upgrade nobody could fund and a point solution nobody could audit.
We built the consent and authorisation layer in front of the core, served partner reads from projections, and gave compliance an evidence trail they could export themselves. The core was not modified.
Talk to us about your estate →Questions
Through whatever the core already supports: APIs, MQ, change data capture, or file bridges. We have connected Temenos, Finacle and Flexcube alongside in-house cores. Nothing about this requires a core upgrade, and we do not put custom code inside the core where a supported interface exists.
Get started
Tell us what you are trying to open up and what the core will and will not allow. An integration architect reviews it and comes back within two working days.
