Trusted Channel

This is not a product brochure.

It is a short note for the people who set direction at a regulated bank — the board members who approve the digital strategy, the digital-banking leaders who own the app, and the chief information security officers who answer to the regulator for it. It argues that the mobile application has quietly become the institution itself, that the same application is now the primary place the institution is attacked, and that the way most banks have defended it — by assembling parts from many vendors — leaves the gaps precisely where they cannot afford them.

It runs in three short movements. The first describes what the app has become and why recognising a threat is no longer the same as stopping it. The second describes the assembled defence most banks now operate, and the seams inside it. The third describes the alternative — one trusted layer, from the hardened shell to the customer destination — and is candid about what that layer does and does not yet do.

The capability detail, the regulatory mapping, and the deployment model live in the accompanying Product Brief. This note is for the decision, not the specification.

The app is the bank — and the target.

For most of a bank's customers, the institution is now a screen. Branches are visited rarely; the relationship manager is a name in a thread; the account, the transfer, the card, the loan, the complaint — all of it happens inside a mobile application. The app is no longer a channel to the bank. For the customer, it is the bank. Payment behaviour has followed: QRIS transaction volume grew by more than two hundred per cent year on year in 2024, concentrating an enormous share of the nation's everyday money movement onto exactly this surface.

The consequence is uncomfortable but simple. The place where the institution now lives is also the place where it is now attacked. Indonesia's financial-services regulator has put the scale of it on the record: reported fraud losses in the order of Rp 7.9 trillion in a single recent year. The methods are mobile-native and industrialised — malicious applications side-loaded through APK droppers, counterfeit banking apps, screen-overlay theft of credentials, account takeover, and the social engineering that ends with a customer moving their own money into a mule account while believing they are being helped.

The bank did not choose to become a mobile-security company. The migration of the franchise onto the phone made it one, whether or not it is resourced as one.

Against this, the industry's oldest defence — a trained eye recognising something as wrong — has stopped being reliable. In an era when a bank's voice, a caller's face, and a plausible message can be manufactured on demand, recognition fails by design; the customer, and often the staff member, is shown something indistinguishable from the real. SMS one-time codes, once the backbone of transaction assurance, are now treated internationally as insufficient for high-risk actions. The defence can no longer rest on anyone noticing.

The regulator has drawn the same conclusion and is turning it into obligation. POJK 11/POJK.03/2022 places IT governance and cyber-resilience inside the core risk-management duty of every supervised bank; its implementing circular SEOJK 29/SEOJK.03/2022 adds specific resilience-testing expectations; and POJK 21/2023 on digital banking services carries a pre-launch independent security-assessment requirement that gives OJK a direct lever over every new mobile banking product. The direction is unambiguous: the bank must be able to demonstrate the integrity of its channel, not merely assert it.

The assembled defence, and its seams.

Faced with this, most banks have done the reasonable thing: they have bought defences. A mobile threat-defence product from one vendor. An application-hardening SDK from another. A secure-messaging tool for staff. A separate customer-chat panel. A fraud-scoring engine. A contact-centre platform. Perhaps a loyalty or lifestyle layer bolted on to keep customers engaged. Each is competent. Most are foreign. And each was built to solve its own slice of the problem.

The difficulty is not in any one part. It is in the seams between them. The mobile-threat product and the fraud engine do not share an identity model, so a device the security stack has flagged as compromised is not automatically a device the fraud stack distrusts. The secure-messaging tool and the contact-centre platform keep separate records, so a regulator's request to produce every interaction with a customer becomes a manual reconciliation across systems that were never designed to be joined. The hardening SDK protects the binary but knows nothing about the conversation happening inside it. The bank has bought security in pieces and inherited the integration — and the risk lives in the gaps the integration cannot fully close.

A bank does not get attacked in the middle of a well-defended product. It gets attacked at the seam between two of them — where no single vendor is accountable and no single audit trail exists.

There is a particular seam worth naming, because regulators elsewhere have already made it expensive. When a bank's own application cannot carry a certain kind of conversation — a relationship manager advising a priority client, a case officer coordinating a fraud response — that conversation does not stop. It moves to whatever channel is convenient, which is usually a consumer messaging app the bank does not own, cannot audit, and cannot produce on demand. Between 2021 and 2025, financial regulators in other markets levied more than three and a half billion US dollars in penalties on exactly this failure of recordkeeping. The exposure is not hypothetical; it is a line item waiting for a local enforcement track to open.

The true cost of the assembled defence, then, is not the sum of its licences. It is the integration burden, the audit fragmentation, the identity that does not carry across products, and the seams that no procurement line ever bought a defence for. A bank can spend a great deal and still be exposed precisely where its vendors' responsibilities end and its own begin.

One trusted layer.

Trusted Channel is the alternative: not another part to add to the stack, but one trusted layer that runs the length of the mobile channel — from the hardened shell the app runs inside, to the customer destination it opens onto. It is a composition of four Nexilis products that share one trust platform, one identity, and one audit trail. Sentinel hardens the device, the application, and the keys, and watches for mobile threats. Enclave carries the bank's conversations — with customers and among staff — inside the app, under encryption and native data-loss control, so they no longer leak to channels the bank does not own. Reach carries engagement and the fraud-and-scam response, turning the moment a customer is being defrauded into a moment the bank can intervene. Plaza carries the commerce, loyalty, and lifestyle destination that keeps the relationship inside the trusted application rather than outside it.

Because the four share an identity and an audit spine, the seams close. A device Sentinel distrusts is a device Reach scores as risky and Enclave restricts — automatically, without a manual join between vendors. A regulator's request to produce every interaction with a customer is answered from one record, not reconciled across five. The conversation that used to leak to a consumer app now happens where the bank can see it and account for it. One vendor is accountable for the whole length of the channel, under one contract, with one audit trail.

The point of Trusted Channel is not that it adds a capability the bank lacked. It is that it removes the seams the bank could not defend — and gives the institution a single, demonstrable account of its own channel.

Two honesties belong here, because their absence would be its own warning. First, Trusted Channel is designed to sit above a bank's existing fraud engines and contact-centre investments as an orchestration layer, not to rip them out — it reduces the integration burden rather than adding a migration to it. Second, it is regulated-ready by construction — mapped to POJK 11/2022, POJK 21/2023, consumer-protection and personal-data obligations, and built to consume Bank Indonesia's SNAP payment APIs securely from the mobile channel — but certification is a posture to demonstrate under evaluation, not a badge to assert, and the sharper intelligence-grade and highest-assurance profiles belong to the sovereign bundle, not this one. A vendor who claims more than this is telling the bank something useful about the vendor.

The invitation that follows is narrow and testable. Most banks do not begin with the whole platform; they begin with the one use case that has a number attached to it — the fraud-and-scam rescue lane, where an intervention that stops a transfer has a direct, measurable value — and they let the trusted layer earn the rest of the channel from there. The specification, the regulatory mapping, and the deployment model are set out in the accompanying Product Brief. What this note asks for is agreement on the shape of the problem: the app is the bank now, it is defended in pieces, and the parts do not add up to a channel the institution can prove it controls.

From hardened shell to customer destination — one trusted layer.

The full capability specification, regulatory mapping, and deployment model are available in the Trusted Channel Product Brief and under NDA.

The trusted mobile layer for regulated banking.

Trusted Channel gives a bank one integrated, regulated-ready mobile platform that runs the length of the customer channel — hardening the device the app runs on, carrying the conversations inside it, orchestrating engagement and fraud response, and holding the commerce and loyalty destination — under one identity and one audit trail.

For most customers the institution is now a screen, and the mobile application is where the account, the transfer, the card, the complaint, and increasingly the relationship all live. That migration has made the app both the bank and the place the bank is attacked. Reported financial-fraud losses in Indonesia run in the order of Rp 7.9 trillion in a single recent year, concentrated on mobile-native methods, while the regulator has moved channel integrity from good practice to obligation under POJK 11/2022 and the pre-launch assessment requirement of POJK 21/2023.

Most banks have answered by assembling a defence from many vendors — threat defence, hardening, secure messaging, a chat panel, a fraud engine, a contact centre, a loyalty layer. Trusted Channel is the alternative: the same span of capability as one platform, so the risk that lives in the seams between products has nowhere to hide. This brief sets out what it is, how each layer works, how it maps to the regulatory frame, how it deploys, what it does not yet do, and how it is priced.

Four products, one trusted layer.

Trusted Channel is a composition of four Nexilis products that share one trust platform, one identity graph, and one audit spine. Each owns a segment of the channel; together they run its full length.

Because the four share an identity and an audit trail, a device the security layer distrusts is a device the fraud layer scores as risky and the communications layer restricts — automatically, with no manual join between vendors, and one record to produce for the regulator.

Proof, not recognition.

The mobile channel is attacked with mobile-native, increasingly AI-assisted methods, against which a defence that depends on a customer or a staff member recognising something as wrong now fails by design. Trusted Channel anchors trust in cryptographic proof, device attestation, and orchestrated response rather than appearance.

Device, application, and key integrity.

Sentinel is the foundation every other layer runs inside. It treats trust as something re-earned on every launch: hardware attestation gates a zero-trust authentication, which in turn gates the delivery of keys that never rest on the device without a live authorisation the bank issues. It combines this with continuous mobile threat defence against the compromised-runtime methods that dominate mobile-banking fraud.

Twelve layers on Android, eight on iOS; the full catalogue and the iOS profile (App Attest / DeviceCheck and Secure Enclave key protection) are provided in the Sentinel technical documentation under NDA.

Bring the conversation inside the app.

Enclave carries the bank's conversations — with customers and among staff — inside the application, bound to devices Sentinel has proven. Confidentiality rests on end-to-end encryption keyed through the bank's own key manager; data-loss controls are native, not a bolt-on. It exists to close the off-channel seam: the relationship-manager thread, the priority-client advisory, and the sensitive internal coordination that would otherwise leak to consumer messaging apps the bank cannot audit.

Turn the moment of a scam into a moment of intervention.

Reach carries engagement and the fraud-and-scam response inside the trusted app. It is designed to sit above a bank's existing fraud engines and contact-centre platforms as an orchestration layer — reducing integration burden rather than replacing investments the bank has already made.

A card or transfer block is a coordinated action through the bank's fraud-management system, card processor, and the networks; realistic end-to-end propagation is in the order of seconds (typically three to ten), not sub-second. A local authorisation flag can be raised faster; full propagation to the networks cannot.

Keep the relationship inside the trusted app.

Plaza carries the commerce, loyalty, and lifestyle destination that keeps customer engagement inside the bank's application rather than migrating to surfaces the bank does not control. It rides the same trust platform as the other three layers, so the destination is not a weaker perimeter bolted to a strong one.

Plaza is included in Trusted Channel where a destination surface is in scope for the deployment; its depth is configured to the bank's strategy during scoping.

Regulated-ready by construction.

Trusted Channel is built to be demonstrable against the instruments OJK, Bank Indonesia, and BSSN actually apply to a digital banking channel. The mapping below is indicative; the authoritative control-by-control matrix is provided under NDA.

SNAP is a payment-API interoperability standard, not a software development kit; Trusted Channel consumes SNAP APIs securely rather than embedding a BI-published SDK. Certification posture is demonstrated under evaluation, not asserted as held.

Regulated-ready out of the box — weeks, not quarters.

Trusted Channel deploys as a hosted or hybrid platform, or on-premises inside the bank's own boundary where required, with the key manager and control plane resident. Because it composes pre-integrated products rather than a systems-integration project across vendors, a defined first deployment lands in weeks rather than quarters.

Three tiers, one platform.

Trusted Channel is licensed as one platform across tiers scaled to the institution, rather than as separately integrated point products. Its commercial case rests on replacing an assembled six-to-eight-vendor stack — threat defence, hardening, secure messaging, chat, fraud, contact centre, loyalty — with a single pre-integrated platform under one contract, removing the integration and audit cost the assembled stack never prices.

Start with the use case that has a number attached to it.

Most banks begin with the fraud-and-scam rescue lane — where an intervention that stops a transfer has a direct, measurable value — and let the trusted layer earn the rest of the channel from there. The full specification and regulatory matrix are available under NDA.