Enclave

The room

inside the app.

On why the banking industry's most important conversations happen in rooms it does not own — and on the architectural move that ends the fragmentation at the level where it began.

PT EASYSOFT INDONESIA · NEXILIS.IO CONFIDENTIAL · FOR BOARD & EXECUTIVE REVIEW

A thesis in four movements.

The note you are holding is an argument, not a brochure. It is written for the institutional reader who already has a Nexilis Enclave product brief on the desk — the document that numbers each section, maps each control, and prices each tier — and who wants the strategic frame underneath. It runs in four acts, each one opening a separate question the reader should be able to answer by the time they close the page. It is short enough to be read in one sitting and structured so that each act can be torn out and circulated on its own if a reviewer only needs the piece that pertains to them.

The thesis, stated here and re-stated in each act, is that the banking industry has mis-framed secure communications as a messaging problem and has bought messaging products against it for twenty years. The category the industry actually needs is not messaging. It is containment. The institution has to build a room, inside the application it already owns, where every conversation of consequence can happen under one identity, one audit, and one policy engine — and cannot happen anywhere else. That room is what Enclave is. The acts below walk through why the existing frame fails, what the correct frame is, how Enclave instantiates it, and what the institution gains when it adopts it.

I. The Leak

The private banker's most expensive conversations happen in rooms the institution does not own.

II. The Room

From secure messaging to containment — the category shift the industry has refused to name.

III. The Fabric

Three modes, one cryptographic surface. How Enclave holds the room together.

IV. The Horizon

What the institution owns, once the room is built, that it cannot own any other way.

I.

The Leak.

A private banker in Jakarta is advising a client on a succession plan. The conversation moves through three platforms in fourteen minutes. None of them belong to the bank.

The private-banking conversation has always been the most valuable conversation in the industry. It is also, today, the most exposed.

A senior relationship manager in a well-known Indonesian priority-banking franchise — the details are anonymised, but the pattern is the common one — begins her Tuesday morning with a client who has signalled, through the bank's scheduling system, that he would like twenty minutes to discuss the transfer of a family business to his daughter. The conversation opens on the bank's own mobile application, in the general-enquiry thread the client uses for card questions and statement queries. Within four minutes, the relationship manager asks for a document. The client is on the move. He takes a photograph of the document with his personal phone and sends it to her on WhatsApp, because it is the channel they have used for the last three years and it is convenient. She opens the photograph on her personal phone, which is the phone she carries in the branch, because the bank's official device does not have WhatsApp installed. She forwards the photograph to the internal trust-services team on the branch's Microsoft Teams chat. One member of that team opens the photograph on his workstation, saves it to the shared drive, and replies with a question about beneficiaries. The RM returns to the client, this time on voice, through WhatsApp Business Call, because the bank's contact centre does not carry high-net-worth clients. The conversation ends with three commitments made, one document shared, four participants involved, three platforms used, one employee's personal phone handling client data, and zero auditable records in the bank's system of record. The total elapsed time is fourteen minutes.

The reader should pause on the end-state. The conversation that just moved the client's succession forward — a conversation with direct revenue, direct fiduciary risk, and direct regulatory exposure — has left no trace inside the institution. The RM's workstation has the photograph in her WhatsApp media folder. The trust-services team has a screenshot on a shared drive. The client has a thread on his personal phone. The bank, which is the counterparty legally responsible for the advice, has nothing. If the client's daughter challenges the succession in three years and claims she was not disclosed the tax treatment, the bank will not be able to produce the conversation that happened on that Tuesday morning. Because the conversation was in three different rooms, none of which belonged to the bank.

§ Why the conversation went where it went

It would be easy, and wrong, to attribute the fragmentation to a training failure. The RM is not untrained. She has been on every communications-compliance course the bank runs. Her manager has signed off, twice a year for six years, on her declaration that she does not conduct business on personal channels. Her declaration is, in the narrow sense, true — she does not intend to conduct business there. But intention is not architecture. The reason the conversation ended up on WhatsApp is that the bank has not built a room in its own application where a conversation of this shape can actually happen. The bank's mobile application carries card balances, transfer screens, product marketing, and a general-enquiry thread that is designed for a retail customer. It does not carry a persistent, named thread between a specific RM and a specific client. It does not carry encrypted voice. It does not carry document exchange with any policy discipline. It does not, in short, do what WhatsApp does — and so the conversation flows to the platform that does.

Multiply that shape by the bank's five hundred relationship managers, by its ten thousand named priority clients, by a year's worth of Tuesday mornings, and the category of exposure becomes legible. Between 2021 and 2025, the United States Securities and Exchange Commission and Commodity Futures Trading Commission levied more than three and a half billion US dollars in combined penalties on this single issue, across more than one hundred of the largest financial institutions in the world. The penalties were not for bad advice. They were for recordkeeping: the institutions could not produce, to the regulator's satisfaction, the conversations their staff had had with clients, because the conversations had taken place on platforms the institutions did not own. The violation was architectural. The penalty was financial.

The violation was architectural. The penalty was financial.

§ The parallel track: the Indonesian window

Indonesia has not yet opened a parallel enforcement track at US scale, and a reasonable reader will ask whether the US experience is instructive here. The short answer is that it is. The Otoritas Jasa Keuangan has already issued the authorising instruments: POJK 11/POJK.03/2022 on the Implementation of Information Technology by Commercial Banks, which places IT governance and cyber-resilience inside the core risk-management obligation of every supervised bank, and its implementing circular SEOJK 29/SEOJK.03/2022 on Cyber Security and Resilience, which sharpens the operational expectation with specific incident-reporting and resilience-maturity requirements. Bank Indonesia's SNAP guidance pushes from the payments side. The Personal Data Protection Act adds a data-sovereignty overlay that every commercial foreign messaging platform, by its own product structure, cannot satisfy. The absence of a visible enforcement action is not evidence that the enforcement will not come. It is evidence that the clock has started.

The institution that starts to build before the window opens is not merely ahead of a penalty curve. It is ahead of a procurement curve: the vendors capable of delivering an end-to-end communications fabric to a Tier-1 Indonesian bank do not scale overnight, and the institution that begins its integration in 2026 will finish two product cycles before the institution that begins in 2028. The leak is already measurable. The question is what the institution does in the two years it has before its regulator forces an answer.

II.

The Room.

The industry has been selling secure messaging for twenty years. That is not what the institution needs. What it needs is a room.

The word messaging has done a great deal of damage to this category.

It has done damage because it has framed the question as a transport problem — how do we move a message securely from A to B? — when the actual problem is a containment problem — how do we make sure that conversations of this class happen in this place and nowhere else? The first framing produces a tool. The second framing produces a room. The tool, once bought, sits on top of the institution's existing fragmentation and secures a slice of it. The room, once built, absorbs the fragmentation and replaces it. Twenty years of vendor procurement has produced tools. The institutions that conclude the 2020s with the exposure under control will be the ones that have, instead, built rooms.

§ What a room is, in this metaphor

A room, in the sense meant here, has five properties. It has a door — a single, identifiable entrance that controls who comes in and records when they did. It has walls — a perimeter that is enforced in hardware and cryptography rather than in policy alone. It has light — an audit stream that makes every action inside the room visible to the institution on demand. It has a ledger — a tamper-evident record of what has happened, from which a regulator-ready account can be assembled. And it has an owner — an identifiable party, in this case the institution itself, which can rotate the keys, retire the participants, and decide what the room is for. Secure messaging tools typically provide one or two of these properties. Enclave provides all five, and provides them as a single architectural artefact.

The metaphor is not incidental to the product name. Enclave is already a term of art to the audience this product addresses. To a CISO, it evokes the trusted execution environment and the secure enclave on the silicon; to a defence communications officer, it evokes the classified enclave on the network; to a banker with any architectural training, it evokes the segmented domain and the policy boundary. The word carries its meaning. It tells the buyer, without further explanation, that the object is a contained space, not a transport protocol. This is what the product is, and the name is the shortest statement of it.

Secure messaging is a tool that sits on top of fragmentation. An enclave is a room that replaces it.

§ The three modes, read as one room

The reader who knows the Enclave product brief will know that the product carries three communications modes: workforce to workforce, customer to customer, and customer to a named workforce counterpart. It is worth re-reading those three modes in the light of the room metaphor, because the point is not that Enclave carries three modes; it is that it carries three modes in the same room. The conversation between the regional manager and his nine branch heads is in the same room, cryptographically and auditably, as the conversation between the private-banking client and his relationship manager, and as the conversation between two customers confirming a transfer memo. One key hierarchy. One identity graph. One audit stream. One policy engine. This is what the fragmented point-solution stack cannot produce — not because the point-solution vendors are incompetent, but because their products are shaped for a slice of the problem and the slices do not fit together.

§ The sovereignty claim

The final property of the room — the ownership property — deserves its own paragraph because it is the property most often conceded without examination. The institution is told, during a standard secure-messaging procurement, that the vendor operates end-to-end encryption and therefore cannot read the institution's traffic. This is technically true and strategically inadequate. The question the institution should be asking is not can the vendor read my traffic. The question is where does the vendor's jurisdiction end and mine begin. If the KMS is in the vendor's cloud, in a jurisdiction that compels disclosure under a court order the institution cannot see, the encryption is doing a narrow kind of work. The institution has a room — but the landlord holds a key.

Enclave is architected so that the institution is the landlord. The keys are the institution's keys, generated in its hardware, rotated on its schedule, retired by its decision. The relay the messages pass through is the institution's relay, deployable on its premises, in its sovereign cloud, or on a national operator's sovereign infrastructure. The cryptographic implementation is written in-house by PT Easysoft Indonesia, without third-party library dependencies in the ciphertext path. This is not a marketing claim. It is a structural property, testable by a security team with a source-code evaluation brief, and it is the claim on which the product's positioning for Indonesian BFSI and for Indonesian government and defence ultimately rests.

III.

The Fabric.

A room needs walls. The walls are cryptographic. Here is what they are made of, and why they matter to the reader on the other side of the evaluation committee.

The previous act made an argument about framing. This one makes an argument about engineering.

An executive reader may, reasonably, prefer not to be taken through the cryptographic primitives. The preference is not the same as the option. The institution's CISO will read these paragraphs, and the institution's state-security reviewer, and the institution's internal audit function; and the quality of the engineering underneath the product is what the room's walls are actually made of. The argument of this act is that Enclave's fabric is built to the bar a regulated-institution evaluation will apply, and that the bar is not the same as the one a consumer-lineage secure-messaging product was built to.

§ The three primitives that do the work

The first primitive is the identity anchor. A conversation in Enclave begins with the establishment of who, exactly, is on each end. Workforce participants are rooted in the institution's identity provider — OIDC or SAML — with FIDO2 passkey as the authenticator, so that the claim this is Jane from branch four can be made with hardware-backed confidence. Customer participants are rooted in the institution's own KYC record — the same identity, on the same device, with the same legal consent and the same lawful basis under the Personal Data Protection Act, that the bank used to open the account. Neither workforce nor customer can participate in an Enclave conversation without a verified, attested, bound identity on a verified, attested device. This is the door.

The second primitive is the key hierarchy. Each installed instance of the Enclave client generates a per-install device key pair, sealed into hardware — Android Keystore with StrongBox where the silicon permits, Trusted Execution Environment otherwise, iOS Secure Enclave on Apple. Message-layer encryption rides on a Double Ratchet construction that advances every message, so that compromise of a single device at time t does not permit retrospective decryption of messages exchanged before t and does not permit forward decryption of messages exchanged after the ratchet has advanced. Session-level transport to the relay is mutual-TLS, with per-session ephemeral keys. Above all of this sits the institution's own key management service — the KMS the institution hosts, operates, and audits — which holds the signing keys for the relay, the policy engine, and the evidence plane. The institution rotates. The institution retires. The institution decides. These are the walls.

The third primitive is the tamper-evident evidence plane. Every action in the room — every send, every receive, every forward, every screenshot attempt, every export, every policy decision — is captured into a hash-chained log structure whose root is sealed periodically into an append-only ledger that can be externally witnessed. When the institution is asked, by a regulator or by internal audit, to produce a conversation, it produces not a message but a timeline: the full sequence of who said what to whom, when, on what device, under what policy decision, with what integrity evidence. This is the ledger, and it is what the fragmented channel map cannot build because the fragmented channel map has no one to write it.

The door admits the verified. The walls contain the traffic. The ledger proves what happened. Enclave is these three things, fastened together into one room.

§ What this means for the three buyers in the evaluation committee

An Enclave evaluation will be read by at least three different readers in the same institution, and each reader is asking a different question. The CISO is asking can I defend this architecture against a sophisticated adversary in a state-security penetration test. The internal audit function is asking can I reproduce the evidence a regulator will demand, on demand, without a vendor ticket. The head of the business — the priority-banking head or the workforce-technology head — is asking does this make my people's conversations disappear into a process they will not use, or does it let them keep working. The architecture described above is designed to answer all three questions in the affirmative: the walls satisfy the CISO, the ledger satisfies the auditor, and the embedded-inside-the-app delivery topology satisfies the business. These are not three separate products. They are three readings of the same room.

A workforce-only secure-messaging tool gives the CISO one-third of the walls. A customer-chat SDK gives the product team one-third of the conversation primitives. A CRM chat panel gives the business head one-third of the RM thread. Three products, assembled by a systems integrator, cannot produce the unified ledger that an auditor needs, because the three products do not share a log format, an identity anchor, or a key hierarchy. The assembled stack is always a negotiation between three vendors and three audit exports. The fourth product — Enclave — is a single room, and the ledger is the room's natural output.

§ The composition, read from inside the portfolio

Enclave does not sit alone in the Nexilis portfolio. It composes with three other products — Sentinel, Reach, and Plaza — and the composition is deliberate. Sentinel hardens the device and the session below Enclave's door: it is Sentinel's job to guarantee that the device presenting itself at the door is genuinely the device it claims to be, and that the application on the device is genuinely Enclave and not a tampered copy. Reach carries the queue-bound service moment above Enclave's fabric: when a customer raises a service ticket, it is Reach's job to route that ticket to the first available agent, and Reach's messaging transport rides on the same cryptographic fabric Enclave provides, which is what makes the room coherent across its modes. Plaza sits above both, carrying community, commerce, and lifestyle — surfaces the end customer chooses to engage with, rather than the conversations the institution must be audited on.

The composition has two commercial shapes. The first is Trusted Channel — Sentinel, Enclave, and Reach, bundled for BFSI — where the three products solve the three layers of the trusted-lane problem that every bank has. The second is TrustLink — Sentinel and Enclave, bundled for government and defence — where the workforce problem is paramount and there is no customer-facing surface to worry about. A third, narrower bundle — the Relationship Banking Stack — pairs Sentinel and Enclave for the priority and private-banking franchise, where the RM thread is the entire franchise and the room has to be built before the franchise's oldest clients move elsewhere. Enclave is the hinge in all three bundles. Remove it and the bundles are not bundles. They are the same fragmented channel map the institution is trying to exit.

IV.

The Horizon.

Once the room is built, the institution owns three things it did not own before. Two are operational. The third is strategic.

A decision to build this room is a decision that keeps paying, in ways that do not all appear on the first invoice.

The immediate return is the one the regulatory frame will force: the institution has, for the first time, a defensible answer to the question produce every conversation your RM had with this client in the last twelve months. The second return is operational: the five-to-seven platforms that any sensitive case currently crosses collapse into one, and the cost of running the sensitive-case backbone — in audit, in incident response, in staff training, in third-party vendor renewals — reduces commensurately. Those are the returns any financial model will capture. The third return is the one the financial model typically cannot price, and it is the most important of the three.

§ What the institution owns, once the room is built

An institution that has built the Enclave room has, for the first time, moved the conversation of consequence inside its own perimeter. Every word an RM has said to a client, every coordination message between head office and branch, every memo between two customers in the same family, is on the institution's substrate, under the institution's keys, inside the institution's audit stream. The immediate consequence is that the conversation — which is to say, the franchise — is no longer a rented asset. It is an owned asset. It can be searched, it can be modelled, it can be risk-scored, it can be used as training data for the institution's own agentic-AI copilots without exporting a byte to a foreign provider. The institution has built an asset that a competitor cannot replicate by signing a WhatsApp Business contract.

This is what the U.S. enforcement track, read correctly, is telling every institution around the world. The regulator is not punishing a messaging failure. The regulator is punishing a failure to possess the conversation. Wall Street paid more than three and a half billion dollars to learn this lesson. Jakarta has the opportunity to learn it earlier, and more cheaply, and — if the architecture choice is made now — with a decisive competitive advantage over the foreign entrants who cannot offer the sovereign version of the room at all.

The regulator is not punishing a messaging failure. The regulator is punishing a failure to possess the conversation.

§ The strategic return

An institution that can produce every conversation it has ever had with a client is an institution that can do things a competitor cannot. It can run a retention model on the signals in those conversations and catch client attrition before it shows up in the transaction log. It can train an internal agentic-AI copilot on its own compliant corpus and ship the copilot to its relationship managers without ever exposing the corpus to a foreign vendor. It can answer a complaint from a daughter in 2029 about a succession conversation her father had in 2026 by playing back the precise sequence of commitments made on that Tuesday morning. It can, in short, use the conversation — and the conversation is the thing that private banking, corporate banking, priority banking, and every relationship-led franchise has always sold and has never been able to possess.

The institutions that win the decade will be the ones that moved this asset onto their own substrate before the regulator forced the move and before the competitor consolidated. The institutions that delay will pay on two lines: they will pay the late-mover penalty on the regulatory side, and they will pay the franchise penalty on the strategic side, because their best relationship managers will continue to carry the conversation on platforms that make the franchise portable. The RM who leaves takes her WhatsApp thread with her. She does not take the Enclave thread, because the Enclave thread is not hers. It is the institution's.

§ The move, stated plainly

The move is to stop treating secure communications as a messaging procurement and to start treating it as an architectural one. The room has to be owned, not rented. The keys have to live inside the institution's perimeter, not in a foreign vendor's cloud. The three modes — workforce, customer-to-customer, and customer-to-named-workforce — have to sit on the same fabric, because the alternative is a three-vendor stack no institution can audit cleanly. And the product that instantiates these choices, in the Indonesian market and on the Indonesian sovereign-cloud substrate, is Nexilis Enclave. The product brief enumerates the controls, maps the regulatory obligations, and prices the tiers. This essay has argued the strategic shape underneath. The institution's next step is to move one of the three modes live — Foundation tier, one mode, shared sovereign cloud, six-to-ten week onboarding — and to observe what happens to the volume of conversation that flows into the room once the room exists.

A typical Foundation pilot covers one mode, one integration point, and shared sovereign-cloud hosting. It lands in six to ten weeks. It produces, by the end of the first quarter, a measurable shift in where the institution's sensitive conversations happen and a measurable baseline for the audit exposure that has, until now, been invisible. A Foundation pilot is the narrowest defensible first move an institution can take against the exposure described in this essay — and the move that creates the most optionality for the architectural choices that follow.

v.

Where trusted conversations live.

The tagline at the top of the Enclave cover page reads where trusted conversations live, and the reader who has arrived here will understand the phrase to be a categorical claim rather than a marketing flourish. Trusted conversations, in the institution worth calling that, live — they are born, they persist, they age, they are retired — inside a room the institution owns. For twenty years that room did not exist for most institutions, and conversations of consequence lived in the meantime in other people's houses. Enclave is the proposition that the interim is over.

The Product Brief that accompanies this essay is the operational document — the layers, the controls, the tiers, the regulatory mapping, the deployment topologies, the service levels. Read it with the argument of these four acts in mind. The two documents are designed to answer different questions, and the reader who holds them both is the reader who has the conversation the institution now needs to have, with the people inside it who will make the architectural decision. That decision is the one this essay has tried to make legible.

PT Easysoft Indonesia — Nexilis Enclave. An executive narrative companion to the Nexilis Enclave Product Brief (April 2026, Revision 1.0). This document is intended for board and executive review under mutual non-disclosure. For commercial discussion, evaluation scoping, or access to the detailed technical-evaluation package, contact nexilis.support@nexilis.io.

The room

inside the app.

Bank-grade encrypted communications embedded inside the host application — covering workforce, customer-to-customer, and named relationship-manager threads. One cryptographic fabric. One identity system. Sovereign-hostable.

Where trusted conversations live.

PT EASYSOFT INDONESIA · JAKARTA — NEXILIS.IO CONFIDENTIAL · FOR INSTITUTIONAL EVALUATION

Nexilis Enclave — in ten movements.

This brief is a technical and commercial reference for Nexilis Enclave — the secure-communications product in the Nexilis portfolio. It is written for chief information security officers, heads of workforce technology, heads of priority and private banking, and the procurement committees who evaluate them. It is organised so that a reader who has thirty minutes can read sections 01, 03, 04, and 09 and come away with a correct picture of what Enclave is, how it is built, and what it costs to own.

Sections 01 and 02 set up the category and define the product in plain language. Sections 03, 04, and 05 are the technical core — they belong to the security architect on the evaluation team. Section 06 is the composition story for procurement teams evaluating Enclave alongside Sentinel, Reach, and Plaza. Sections 07 and 08 are the competitive and regulatory frame. Sections 09 and 10 carry the commercial and operational detail a procurement lead needs to model the deal.

Conversations that leak the institution.

A bank's most sensitive conversations — the relationship manager advising a private-banking client on a succession plan, the fraud officer coordinating across three branches to freeze an account, the two treasury staff confirming a large-value instruction between themselves — do not happen where the bank thinks they do. They happen on the WhatsApp threads the staff already have open. They happen on SMS. They happen on the one consumer app everyone in the branch uses because it is easy. They happen, in short, in rooms the institution does not own.

This is not a failure of training. It is a failure of architecture. The institution has invested in core banking, in fraud systems, in mobile apps, in contact centres, in device management — and yet the conversations that move risk, relationship value, and regulatory liability still flow through external consumer channels because no one ever built the internal channel properly. The external channels are convenient. The internal ones, where they exist at all, are fragmented: a secure messaging app for the compliance team, an MDM for the field officers, a separate video platform for branch managers, a priority-banking CRM with its own comms pane that nobody uses. Four tools, four identity systems, four audit trails — so staff default to the one tool that works everywhere, which is the one the institution cannot see.

The consequences are no longer hypothetical

Between 2021 and 2025, the US Securities and Exchange Commission and Commodity Futures Trading Commission levied more than USD 3.5 billion in combined penalties — with additional actions by FINRA — against more than one hundred firms for a single category of failure: recordkeeping violations arising from staff conducting business communications on personal devices and consumer messaging platforms. The UK Financial Conduct Authority, the European Securities and Markets Authority, and the Monetary Authority of Singapore have opened parallel enforcement tracks. These are not edge cases. These are the largest and most sophisticated institutions in the world, losing billions, because their staff used WhatsApp to talk about work.

Indonesia is not exempt from this trajectory. Otoritas Jasa Keuangan's POJK 11/POJK.03/2022 on the Implementation of Information Technology by Commercial Banks, and its implementing circular SEOJK 29/SEOJK.03/2022 on Cyber Security and Resilience for Commercial Banks, already require risk-based cyber-resilience governance. Bank Indonesia's SNAP SDK guidance pushes in the same direction for payments. The Personal Data Protection Act adds a lawful-basis and data-sovereignty overlay that commercial messaging platforms cannot satisfy. The regulator is not a question of whether, only of when, the enforcement window opens in Jakarta on the same category that cost Wall Street more than three-and-a-half billion dollars.

The category the market has misnamed

For two decades the industry has framed this as a secure-messaging problem and sold secure-messaging products against it. That framing is incomplete. Secure messaging, as sold by the global incumbents, addresses one mode of the problem — staff-to-staff communication — and leaves the other two untouched. It does not address customer-to-customer conversations happening inside the bank's own app. It does not address the persistent one-to-one thread between a private-banking client and their relationship manager, where the franchise value of wealth management actually lives. And it does not provide the single cryptographic fabric across all three modes that makes audit, key rotation, and policy enforcement tractable for a regulated institution.

The correct framing is not secure messaging. It is containment: the institution building a room, inside the application it already owns, where every conversation of consequence happens under one identity system, one audit trail, and one policy engine — and cannot happen anywhere else. That room is an enclave. This product is Nexilis Enclave.

What Enclave is, in one paragraph.

Nexilis Enclave is an embedded communications fabric — a software layer that sits inside the institution's existing mobile application and delivers bank-grade encrypted messaging, voice, video, group threads, and file exchange across three modes: workforce to workforce, customer to customer, and customer to a named workforce counterpart. Every conversation carried over Enclave is bound to a verified identity, observed by a single policy engine, recorded in a single regulator-ready audit stream, and encrypted end-to-end under keys the institution — not a foreign vendor — is able to rotate, escrow, and retire. The product can be embedded into an existing banking app, deployed as a white-label companion app, or delivered as a hardened sovereign build for government and defence.

What Enclave replaces

The WhatsApp group used by a regional manager and nine branch heads to coordinate a product rollout.

The SMS thread between a relationship manager and a private-banking client about a structured product.

The consumer video-call app used by a compliance officer to interview a new high-net-worth applicant.

The informal payment-memo message a customer sends a family member about a transfer, today done on a social network.

The point-to-point enterprise-messaging tools (Wickr, Element, Signal Enterprise, Threema Work) a security team licenses to solve only the workforce slice of the problem.

The embedded-chat SDKs (Sendbird, Stream, CometChat) a product team licenses to solve only the customer slice.

The bespoke relationship-manager chat panel inside a CRM, which most staff abandon within six months.

What makes Enclave different

Nexilis Enclave is bank-grade encrypted communications embedded inside the app — covering workforce, customer-to-customer, and named relationship-manager threads. One fabric, one identity, sovereign-hostable.

Workforce. Customer. Named counterpart.

Most secure-communications products address one mode and leave the other two to other vendors. Enclave carries all three on one fabric. The three modes are distinct in purpose, user interface, and commercial metric — but they share the same cryptographic primitives, the same identity provider, and the same policy plane. This section defines each mode, the persona it serves, and the operational pattern it replaces.

The boundary rule: relationship versus service moment

Because the customer-to-workforce axis overlaps with a contact centre, the boundary between Enclave and Nexilis Reach is stated as a rule the institution can enforce in product design. Enclave is identity-bound, persistent, and tied to a named counterpart — a relationship manager, an account officer, a private-banking concierge. Reach is queue-bound, transactional, and routed to whichever agent is free. Both can live in the same bank application, using the same underlying comms primitives — Reach's messaging transport runs on the Enclave fabric — but the products are sold on different metrics: Enclave on seats and persistent threads, Reach on conversations and engagement outcomes.

A workforce-only secure-messaging purchase solves one vector. A customer-chat-SDK purchase solves another. A relationship-manager CRM purchase pretends to solve a third. Three vendors, three contracts, three audit systems, three sets of key escrow, three renewal cycles. Enclave is one contract. That consolidation, on its own, is why the commercial evaluation simplifies well before the technical review begins.

Which mode to activate first

Most institutions activate Enclave in one of three entry patterns. A regulatory-pressured bank typically activates W↔W first to close the SEC-style enforcement risk on off-channel comms. A priority- or private-banking franchise typically activates C↔W-named first to bring the relationship-manager thread inside the institution's audit perimeter. A consumer-scale digital bank typically activates C↔C first to deepen engagement inside the app and reduce dependence on external social-messaging platforms. The three-mode fabric supports all three sequences without architectural change.

The six-layer enclave fabric.

Enclave is a layered product. The layers are not marketing artefacts — they correspond to the engineering teams, the interface contracts, and the control-plane responsibilities that the institution's integrators will encounter. Each layer is independently testable, independently upgradable, and independently auditable. Sentinel's hardening envelope applies below Layer 1; Reach and the host banking application sit above Layer 6.

Device hardening, root and jailbreak detection, malware scanning, anti-tamper, and DEX protection are not in Enclave. Those are Sentinel's job. Enclave assumes Sentinel runs below it and consumes Sentinel's device-posture signal to feed Layer 5 policy decisions. The two products ship together in the Trusted Channel and TrustLink bundles.

Keys, devices, and provenance.

The cryptographic design of Enclave is built to withstand a specific class of regulated-institution evaluation — one where the CISO's team will read the key-derivation chain, one where the internal audit team will test evidence replay, and one where the state security agency's technical reviewer will ask where every key in the system ultimately lives. This section summarises the model at the level a technical evaluator needs; a detailed cryptographic specification is provided under NDA.

Identity anchors and device binding

Every Enclave participant — whether workforce or customer — is rooted in an identity anchor. For workforce, that anchor is the institution's identity provider: OIDC or SAML, with FIDO2 passkey as the authenticator. For customers, the anchor is the institution's own digital-onboarding KYC record — the same identity bound to the customer's banking relationship. Both anchors commit to a per-install device public key at first enrolment. That device key is generated in hardware — Android Keystore with StrongBox where available or the trusted execution environment otherwise, and iOS Secure Enclave — and never leaves the device.

Message and session key hierarchy

Message-layer encryption uses a Double Ratchet construction, seeded from a prekey exchange at first contact between two identities. Every message uses a fresh chain key; compromise of a single device at time t cannot decrypt messages exchanged before t (forward secrecy) and cannot decrypt messages exchanged after t once the ratchet has advanced (post-compromise security). Session transport to the relay uses a mutual-TLS channel with per-session ephemeral keys; bulk ciphertext is AEAD under AES-256-GCM or ChaCha20-Poly1305 depending on platform policy.

Sovereign key management

The institution operates an Enclave KMS — deployable on-premises, in sovereign cloud, or in Telkom Sigma — which holds the institution's signing keys, the relay's signing keys, and the policy-signature keys. The institution can escrow, rotate, or retire any key in the hierarchy without vendor dependency. Nexilis as a vendor does not hold cryptographic escrow over any institution's ciphertext; the audit of this claim is structural, not contractual, because the relay is explicitly designed to be unable to decrypt message payloads.

The cryptographic primitives used in Enclave — AES-GCM, ChaCha20-Poly1305, X25519, Ed25519, HKDF, and the Double Ratchet — are standards-defined. The implementation is built by PT Easysoft Indonesia on a deliberately minimised cryptographic supply chain drawing from auditable, widely reviewed sources; the complete Software Bill of Materials for the ciphertext path, together with per-component provenance and upstream versions, is disclosed in full to qualified institutional evaluators under NDA. The product contains no closed-source or unreviewed third-party code in the ciphertext path. This is the claim behind the sovereign-hostable positioning and is testable by independent review.

Evidence and replay

Every conversation event — send, receive, forward, screenshot attempt, export, policy decision — is captured into a tamper-evident log chain on the Layer-6 evidence plane. Each entry is individually hash-sealed and chained to its predecessor; the chain's root is sealed periodically into an append-only ledger that can be externally witnessed. On demand, the institution can replay a full case timeline — every participant, every action, every policy decision — into a regulator-ready export. This is the capability that today's fragmented channel stack cannot produce and that US SEC enforcement actions have demonstrated regulators will demand.

Enclave inside the Nexilis portfolio.

Enclave is sold three ways: standalone, as a component of two vertical platforms (Trusted Channel for BFSI and TrustLink for government and defence), and as a component of a sharp bundle aimed at relationship-led banks (the Relationship Banking Stack). The composition logic is deliberate — every Nexilis product can be sold alone, but each vertical platform packages the set that a particular market buys as a unit.

Enclave sold standalone

Enclave is also available as a standalone product. A security team that has already standardised on other mobile-security and engagement vendors can license Enclave as the communications fabric alone, integrating it against its existing identity provider, its existing audit systems, and its existing banking application. A standalone deployment is a natural step for institutions that are part-way through a multi-year contract with an incumbent secure-messaging vendor and are beginning to look at the renewal. Enclave's three-mode fabric is the architectural differentiator no workforce-only product is structured to provide, and the standalone licence makes it possible to introduce that fabric without waiting for the incumbent term to expire.

Path to a fuller deployment from a standalone start

A standalone Enclave deployment typically surfaces, during evaluation, a set of adjacent questions the institution does not intend to leave unanswered. The question of device-posture trust — what happens if the device is rooted, what happens if the app is tampered with, what happens if a keyboard-injection attack captures a plaintext draft — sits in Sentinel's territory, and institutions that have completed an Enclave evaluation are typically in a position to open the Sentinel conversation within six months. The question of service-moment traffic — the inbound ticket that belongs in the same trusted channel as the sensitive conversation — sits in Reach's territory, and is the third adjacency an institution is usually ready to close once the first two are in place.

Buyers and procurement teams sometimes ask whether Enclave is 'the secure-messaging module' of Trusted Channel or a standalone product. The answer is both — and the correct framing is that Enclave is a product in its own right, addressed and sold by itself, and that Trusted Channel is a bundled commercial offering composed of three of Nexilis's standalone products. The same SKU structure applies as to Microsoft's portfolio, where Teams is both a standalone product and a component of Microsoft 365.

Why none of the incumbents cover all three modes.

Enclave does not compete against a single incumbent. It competes against the unavoidable vendor sprawl that a regulated institution today has to assemble because no single product on the market delivers all three communications modes on one cryptographic fabric. The table below is the competitive landscape as an institutional evaluation would assemble it.

Where the competition is strongest

Two competitors warrant specific treatment. Wickr is a mature and capable product on the workforce mode alone, and an institution already operating under a multi-year Wickr contract is unlikely to reopen the question on comparison alone. The architectural case, rather, is that a single-mode workforce platform addresses one-third of the sensitive-conversation problem — the customer-to-customer and customer-to-named-workforce modes remain outside its scope, typically handled by separate stacks with separate key hierarchies and separate audit systems. Enclave consolidates the three modes into one cryptographic fabric, one identity model, and one audit stream; the total cost of ownership across the three lines falls below the combined cost of three stacked vendors within the first renewal cycle.

Off-channel enforcement and the POJK / PDP stack.

Enclave is designed to satisfy three concentric regulatory frames: the global off-channel-communications precedent (SEC, CFTC, FCA, ESMA, MAS); the Indonesian financial-services framework (OJK POJK 11/POJK.03/2022 and its implementing circular SEOJK 29/SEOJK.03/2022, Bank Indonesia SNAP SDK); and the Indonesian data-protection and data-sovereignty overlay (UU PDP). Each control in Enclave maps to one or more requirements in each frame.

OJK has not yet opened a publicised off-channel-communications enforcement track comparable to the US SEC's 2021–2025 action line. The direction of travel across the published authority and guidance is nevertheless clear: POJK 11/POJK.03/2022 establishes the IT-governance authority, SEOJK 29/SEOJK.03/2022 tightens the cyber-resilience and incident-reporting expectation, and OJK's informal guidance on electronic-communications governance is moving. The enforcement window is a question of when, not whether. Institutions that move before the window opens are positioned; institutions that wait will move under penalty.

What Enclave does not claim

Enclave does not claim to discharge the institution's regulatory obligations — no vendor product can. Enclave claims to provide the controls the institution needs in order to discharge those obligations, and to produce the evidence the institution needs when a regulator asks. The distinction is important: the responsibility stays with the institution, and Enclave is architected to make that responsibility tractable.

Foundation. Growth. Enterprise.

Enclave is packaged in a three-tier ladder mirroring Sentinel and Reach — Foundation, Growth, and Enterprise — structured so institutions can begin at Foundation with a single mode and expand as governance scope, scale, and sovereignty requirements deepen. The commercial metric at Foundation and Growth is active seats or active customers; the commercial metric at Enterprise is a committed platform fee with a seat band. Pricing below is a reference range; the actual commercial structure is set in the quotation against the institution's specific seat profile, deployment topology, and support tier.

Commercial metrics and sizing

For the workforce mode, Enclave is sized on named authenticated seats. For the customer-to-customer mode, Enclave is sized on the addressable active-customer population of the host application — with a pricing grade that falls sharply at scale (above 500k customers the per-customer unit is a fraction of the workforce seat cost). For the customer-to-named-workforce mode, Enclave is sized on the number of named relationship-management pairings — typically the priority- or private-banking RM book. A typical three-mode deal for a mid-tier Indonesian BPD (2,000 workforce, 800,000 customers, 120 RM pairings) prices at Growth tier in the mid- to high-single-digit IDR billion range per annum, before sovereign-hosting surcharges.

Add-ons available at any tier

Sovereign-hosting surcharge — on-premises or in-country sovereign cloud; includes KMS co-residency and sealed relay.

Premium cryptographic audit — annual independent review of implementation, key lifecycle, and evidence integrity.

Regulatory-pack updates — continuous delivery of policy templates tracking OJK, BI, and BSSN regulatory evolution.

Relationship-Manager Concierge integration — deep integration with the institution's CRM for the C↔W-named thread.

Defence-grade communications pack — incremental hardening and custom policy library for TrustLink-deployed configurations.

Deployment, operations, and support.

Enclave is delivered in one of three deployment topologies — embedded SDK, white-label companion app, or sovereign build — and runs in one of three hosting modes. The choice of topology is determined by the institution's existing mobile application estate and integration appetite; the choice of hosting mode is determined by regulatory requirement and sovereignty preference.

Three deployment topologies

Integration and onboarding

A typical Foundation deployment — one mode, one integration point, shared sovereign-cloud hosting — onboards in six to ten weeks from contract signing to first live conversation. A Growth deployment — two modes, SIEM integration, dedicated tenant — typically lands at twelve to sixteen weeks. A full Enterprise deployment with sovereign KMS and on-premises relay is a three- to five-month program. The deployment team is composed of Nexilis platform engineers, a dedicated solutions architect, the institution's own identity and mobile-app teams, and where relevant the institution's preferred systems integrator.

Support and service levels

The 99.95% availability target at Enterprise tier is supported by a documented reference architecture: active-active deployment across two in-country availability zones, synchronous replication of the evidence plane, asynchronous replication of the relay state, and automated failover under a measured recovery-time objective of fifteen minutes for the control plane and sixty seconds for the relay. The target availability and severity-response times are backed by an Indonesia-based 24×7 support operation with Bahasa Indonesia and English coverage, fielded by PT Easysoft Indonesia platform engineers escalating to named solutions architects. The full reference-architecture specification, the HA/DR run-book, and the staffing model for each tier are included in the technical-evaluation package provided under NDA.

Evidence, certifications, and deployment references

A product brief is the first document in an institutional evaluation; it is not the last. The evidence that backs the claims in this brief — deployment references, certification status, penetration-test summaries, cryptographic audit reports, the Software Bill of Materials, the HA/DR reference architecture, and the policy-library source — is assembled into a separate Technical Evaluation Companion, released to qualified institutional evaluators under mutual non-disclosure.

Enclave's certification posture is tracked openly and included in every technical-evaluation pack. The current status across the certifications most commonly asked about in Indonesian BFSI and government evaluation is: ISO/IEC 27001 — in scope, audit cycle active; SOC 2 Type II — in scope, reporting period active; PCI-DSS (relevant for BFSI scope) — assessment in progress; BSSN evaluation (relevant for TrustLink / critical-information-infrastructure deployments) — submission in progress; FIPS 140-3 cryptographic module validation — planned for the post-quantum migration cycle. The up-to-date certification matrix, including the assessor name, audit period, and accessible attestation letter for each line, is provided in the technical-evaluation pack. Where a certification is not yet held, the expected attainment date and the compensating controls relied upon in the interim are documented alongside.

Nexilis Enclave is a product of a young and focused vendor, and its deployment base reflects that: the product is in the earliest institutional deployments in Indonesian BFSI and in qualified-pilot engagements with Indonesian government and defence stakeholders at the time of this brief. Specific deployment references, named or anonymised at the institution's preference, are shared with qualified evaluators under NDA. PT Easysoft Indonesia is transparent about the pre-reference stage of certain engagements and commits that any claim made in the evaluation conversation is grounded in a traceable customer case or a declared gap; no customer evidence is presented that does not exist.

Enclave's cryptographic road-map tracks NIST's post-quantum standards (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, finalised August 2024). The crypto-agility architecture of the product permits hybrid-classical and post-quantum schemes to be delivered as a policy-library update rather than a breaking engine change. The migration timeline, hybrid scheme details, and test-vector status are documented in the technical-evaluation pack.

Upgrade path and version policy

Enclave is delivered on a continuous-delivery cadence with a quarterly long-term-support release that institutions can pin against change-management and audit cycles. Security fixes are delivered out-of-band on critical severity and do not disturb the LTS line. Policy-library and regulatory-pack updates are delivered independently of the platform release, so an institution can accept a regulatory refresh without accepting an engine upgrade.

End of Product Brief. This document is intended for institutional evaluation under mutual non-disclosure. Architectural details, cryptographic specifications, adversarial audit findings, and control-mapping appendices are provided as a technical-evaluation package to qualified evaluators on request. For commercial enquiries, procurement discussions, and proof-of-concept scoping, contact PT Easysoft Indonesia at nexilis.support@nexilis.io.