Technical support powered by AI with increased efficiency

1. DARCA solution summary

Support at DARCA is a product layer: in-app chat always at hand, omnichannel with a single case, action-support via buttons and deep links, and a multi-layer AI system for speed, quality, and security.

Info

Support at DARCA is a part of the platform, not a “call center”: it operates on the principles of core + modules, real-time statuses, and security-by-design.

At DARCA, customer service is designed as a full-fledged product layer inside the app. Not “we explained what to tap”, but “we guided the user to a result”. This solution is built so that support is одновременно: fast, secure, scalable across languages and time zones, and at the same time does not turn into a attack surface for fraudsters.

Access to support: help always nearby, without searching or waiting

At any moment inside the app, the chat opens with a swipe from right to left. This is intentionally done so that help is always nearby, without searching for “where is support” and without navigating menus.

Then the chat works as a control center, not as a “messaging window”. If a user asks how to perform an action, we do not limit ourselves to a text instruction. We guide the user to a concrete result and provide an exact transition or action via a button.

Tip

Action-support logic: instead of “go there and tap this”, the user gets a button that leads to the required screen or запускает a scenario.

Examples of how this looks conceptually:

• “check the transaction status” - button “Open status”
• “need a statement” - button “Generate statement”
• “need to confirm an action” - button “Confirm in the app”
• “need documents” - request for documents or files directly in the chat

Example

At DARCA, the chat does not end with an answer. An answer must end with an action or a clear next step.

Omnichannel without context loss: one case, one history, one result

The primary support channel is the in-app chat. Additionally, support is available in popular messengers (Telegram/WhatsApp/WeChat/iMessage, etc.). The key principle: regardless of which channel the client uses, we always have a single case, a single timeline, and a single context, so the user does not repeat the same problem multiple times and support does not “break” when switching between channels.

Note

Omnichannel at DARCA is a single case and a single history, not “different chats in different places”.

Zero tolerance for fraud: we eliminate calls entirely

We completely eliminate calls as a service channel:

• DARCA does not call users
• DARCA does not accept calls

This is done deliberately because calls are the most convenient tool for fraud and Social engineering. We deliberately build a user habit: any call allegedly from DARCA is fraud. All actions happen only in verifiable digital channels: the app and official messenger accounts.

Warning

Any call “from DARCA” is considered fraud. Official actions take place only through the app and official channels.

Separation of powers: support helps, but cannot “take money”

Support at DARCA must not be a point through which money can be stolen “under the guise of help”. Therefore:

• the bot and the operator can explain, guide, help, and perform non-critical actions, as well as send documents
• any critical actions (transactions, confirmations, signatures) are performed only via a button and confirmed by the user themselves in the app

Danger

Critical operations cannot be “done for the client”. Even if an operator is involved, the final confirmation and action are only on the user’s side.

AI in support: a three-layer system, not “one chatbot”

We use AI as a permanent service layer, not as an “optional feature”. It operates at different levels:

1. AI for the user

• responds 24/7
• understands the request
• guides through scenarios
• provides buttons and deep links
• requests documents and files directly in the chat

2. AI co-pilot for the operator

• raises the context even before the operator connects
• suggests response options
• suggests action buttons and scenarios
• accelerates case resolution on the first contact

3. AI for quality control

• produces summaries of dialogues
• evaluates resolution quality
• identifies frequent support topics
• helps improve the knowledge base and the product

Info

AI in DARCA solves two tasks simultaneously: speed for the user and controlled quality for the platform.

24/7 and all languages: scaling by architecture, not headcount

Support must operate around the clock and in all languages, but without massive costs. We do this as follows:

• the user writes in any language
• the system detects the language and helps translate
• the operator receives context and a ready translation
• at night and on weekends, AI handles the bulk of requests, and a small team connects via on-call for critical cases

Tip

We scale support not by the number of people, but by architecture and automation.

Support as an ecosystem: Academy, Universal Assistant, Autopilot, Messenger Module

Support evolves into a set of connected layers that reduce errors and increase user self-sufficiency:

• DARCA Academy - education and error reduction
• Universal Assistant - an assistant “for any questions”
• Autopilot - automatic prompts: transaction search, reminders, scenarios
• evolution into a messenger module with financial functions (transfers in chat, loans, documents/signatures), while everything critical is still confirmed by the user

Question

Why is this important?
Because the best service is the one that prevents an error before a request: through education, prompts, and correct scenarios.

Why this model is stronger than traditional bank support

A traditional bank tries to “speed up” by hiring. DARCA speeds up by the fact that:

• access to help is instant
• the answer ends with an action, not just text
• context is not lost: one case in an omnichannel flow
• calls are excluded: lower fraud risk
• AI handles the standard flow, the operator is reinforced by a co-pilot, and quality is controlled by a separate AI layer

Below is a simplified flow logic:

• the user writes in the chat (in-app or messenger)
• AI understands the request and proposes a solution
• if needed, an operator connects with ready context
• the result is recorded: action, document, status, summary
• frequent issues go into analytics and improve the product

Note

Final goal: the user feels control and security, and the platform gets a scalable service model without loss of quality.

2. Problem and requirements for the target service

We capture market pain points and turn them into measurable requirements: DARCA support must be fast, secure, omnichannel, and scalable without inflating headcount.

Info

This section is a quality contract. If a requirement is not met, we do not consider support to be “ready”, even if there is formally a chat and operators.

The problem of the support market is not that “banks are not trying”, but that service is often built around internal processes rather than around the user. As a result, typical pains appear: responses are slow, the service does not work 24/7 where it is critical, first-contact resolution quality is low (FCR drops), the user is forced to repeat the same thing again and again, and automation is irritating and turns into a labyrinth. Add to this a failed digital onboarding, where a person “drops off” simply because they do not understand the next step or do not see a status, and we get the most dangerous outcome: loss of trust and rapid churn. When service is bad, the user usually does not argue - they leave, especially when money and security are involved.

Warning

Service destroys trust faster than marketing builds it: the user leaves not because of price, but because of the feeling “they do not hear me”, “they are not helping me”, and “I do not understand what is going on”.

From these pains we derive requirements that become mandatory and non-negotiable. First, support must be available at all times: 24/7/365, without “business hours”, so that the user does not think “are they even responding right now?”. Second, it must work in any language, because global scaling is impossible if language is a barrier. Third, support must be omnichannel, but not in the form of “different chats”, rather as a single case and a single context: wherever the dialog starts (in the app or in a messenger), the user does not repeat everything from scratch, and the operator sees the history and the current status.

The next requirement is speed as a standard. Typical questions must be closed instantly, complex ones quickly and with a clear sense that “my case is in progress”. Here, not only response time matters, but also the ability to close a case on the first contact. Therefore, for us the key metric is FCR: the user must receive a solution, not endless clarifications and handoffs.

At the same time, the service must be secure by default. Support cannot become a fraud channel, and therefore any actions related to money, blocks, confirmations, or signatures must be confirmed by the user inside the application. No “we will call you and resolve it” and no scenarios where an operator can perform a critical action “for the client”.

Danger

Support must not create a new risk. Everything critical is confirmed by the user in the application, otherwise the service becomes an attack point.

Finally, scaling must not happen “linearly”. Growth cannot be solved simply by hiring more operators: it is expensive, slow, and unstable in terms of quality. Therefore, the requirements immediately include an architecture where AI handles typical requests, prepares context and solutions for the operator, and a human steps in where accountability, exceptions, or complex cases are needed. This is not a “checkbox chatbot”, but a system that improves quality, reduces repeat обращения, and makes the service manageable.

To ensure these requirements do not remain just words, we fix a set of DARCA solutions and constraints. First - the No Calls policy: we do not call and do not accept calls, and any call “from DARCA” is considered fraud. Second - Chat-first access: the in-app chat is always available (swipe from right to left) and is the primary service and support channel. Third - “action chat”: both the bot and the operator can provide buttons and deep-links so that the user does not read instructions but performs the action immediately. Fourth - separation of powers: the operator can perform non-critical actions and send documents, but everything critical (transactions, confirmations, signatures) is executed only through a button and user confirmation in the app. Fifth - omnichannel via messengers: in addition to the in-app chat, support is available in popular messengers (Telegram/WhatsApp/WeChat/iMessage, etc.), but with the same rules for critical actions and documents. Sixth - AI operates at all levels: the AI assistant communicates with the client 24/7, the AI co-pilot helps the operator, and the Supervisor AI controls quality, produces summaries, and identifies recurring requests to improve the product. Additionally, AI acts as a universal assistant “for any questions”, is part of DARCA Academy, and can run personal automations (reminders, transaction search, daily digests, etc.).

Example

Support is considered achieved only if there are no dead ends, context is not lost, and the resolution path leads to a result. If this is not fulfilled, we do not consider the problem solved.

3. DARCA Customer Service Principles

We define the principles by which support, AI, and processes are designed so that the service remains fast, secure, and high-quality at any scale.

Note

These are not “generic words”, but design rules. If we deviate from them, support stops being scalable and secure.

We build support so that it works equally well at any scale: from 10,000 to 10,000,000 users. For this, support in DARCA cannot rely on “heroic operators” or on lucky shift schedules. It is designed as part of the platform under strict rules: chat-first, action-first, context-first, security by default, and scaling through AI rather than through linear headcount growth.

Chat-first: a single entry point into help and product scenarios

The service starts with the user not having to search for support. The chat is always available and opens with a swipe from right to left from anywhere in the app. This turns the chat into the primary interface for help, where the user receives not only answers, but also a clear path to a solution. Through the chat, a person enters support, sees transaction statuses, receives documents, launches scenarios, goes through training (Academy), enables personal automations (Autopilot), and uses the universal assistant for any questions. What matters here is not the number of functions, but the principle: the user has one place where “everything starts” and where they do not get lost in menus.

Tip

The chat-first principle reduces fragmentation: instead of dozens of entry points and “where do I find this”, the user has one clear route.

Action-first: the dialogue ends with an action, not with a conversation

In DARCA, we do not build support around long instructions. We build it around results. This means that almost any answer in the chat contains two parts: a short explanation of “what is happening” and the next step, presented as a button or a precise action. This creates action-support: instead of “go there, then click this”, the user gets a deep-link to the required screen, or a ready-made action (for example, generate a statement or request a document), or a confirmation inside the app if it is a critical step.

For clarity, we fix the types of “next step”:

• Deep-link: open the required screen, section, specific transaction, status, or case
• Action: generate a statement, request a document, enable or disable a module, create a case, submit a form, start a verification
• Confirm: confirm a critical action inside the app (money operations, signatures, changing critical settings)

Warning

The action-first rule: if the user has to perform 5 manual steps, we must turn this into one scenario and one button.

Context-first: decisions are made on full context, not on guesses

Speed and quality are impossible without context. That is why support and AI work by the context-first principle: the service always pulls the maximum available information in order to close cases on the first contact and without repetitions. Context includes the history of dialogues and requests, transaction and case statuses, security events (logins, new devices, suspicious activity attempts), product activity history (where the user “got stuck”), transactions and payment patterns (for hints and automations), documents and forms that have already been provided, as well as communication preferences and assistant settings.

This is used in the same way at two levels. AI sees the context and immediately proposes the correct scenario. When the operator connects, they receive not a “clean chat”, but a summary, key facts, and recommended actions with buttons. This directly increases First call resolution and reduces the number of repeat requests.

Info

Context-first accelerates the service without loss of quality: fewer clarifications, fewer repetitions, higher solution accuracy.

No-call policy: calls are excluded as an anti-fraud standard

Phone calls are the most convenient channel for fraud and Social engineering. Therefore, DARCA operates under the No Calls policy: we do not call users and we do not accept calls. Any call “from DARCA” is treated as fraud. We закрепляем this in the product, in training, and in chat scenarios so that the user forms a stable security habit. Official actions are performed only in verifiable digital channels: the in-app chat and official accounts in messengers.

Danger

No-call policy is not a “limitation”, but an anti-fraud standard that reduces social engineering risks and increases trust.

Small trusted team + AI: people as special forces, AI as scaling

DARCA does not scale support linearly by the number of operators. We scale by architecture: AI closes mass questions, translates into any languages, helps the operator respond faster, and controls quality. People connect as “special forces” where responsibility, non-standard solutions, or control of critical cases are needed. At night and on weekends, AI closes the main flow, and a small trusted team works on on-call for critical situations.

Here, not only the assistant for the user is important. We have AI working at several levels:

• AI assistant communicates with the user 24/7
• AI co-pilot helps the operator (context, answer options, action buttons)
• Supervisor AI evaluates quality, produces summaries, and identifies reasons for requests

Example

The user writes in any language and at any time, the service responds quickly and in a consistent style, and critical cases do not “fall through” because of time zones.

No critical actions without the user: support is not a breach point

Support must not create a new risk. That is why we strictly separate authorities. The bot and the operator can perform non-critical actions, issue documents, request documents, accompany, and help. But everything related to money, confirmations, signatures, and security changes is performed only via a button and confirmation by the user inside the application. The operator can prepare an action, but it is always executed by the user.

Danger

A critical action without user confirmation is impossible. This protects against fraud and increases trust in the service.

Service as a product: support reduces the number of problems, not “puts out fires”

Support in DARCA does not live separately from the product. We use it as a mechanism to improve the system. Supervisor AI and analytics identify recurring questions, points where users get stuck, causes of negative experience, and non-obvious interface elements. This is then turned into concrete changes: interface improvements, onboarding, statuses, knowledge base, automations (Autopilot), and lessons (DARCA Academy). The fewer mistakes and stuck moments a user makes, the fewer requests, the higher the trust, and the lower the cost of service.

Tip

The best service is the one that prevents a problem before a request: through education, hints, and correct scenarios.

Modularity: support grows as a platform, without overload and without a monolith

Support evolves according to the core + modules principle, just like the entire bank. The base Support Chat is always enabled, and additional contours are connected modularly: Academy, Universal Assistant, Autopilot, and далее Messenger Module. This makes it possible to develop the service without overloading the interface and to show the user only what they actually need. The rule is simple: the service grows, but the product does not turn into a monolith.

4. Client support interface

Support in DARCA is a contextual interface inside the product: it is always available, shows statuses, and leads the user to a result through actions, buttons, and secure confirmations.

Info

We build support as a superpower of the application: it is always nearby, understands the context, and resolves issues, not just chats.

For support to truly close the market pain of “low service quality”, it must start not with an operator and not with scripts, but with the interface. The interface is what determines whether the user will feel in control, get fast solutions, and trust the system, or get lost in menus, wait for answers, and repeat the same thing over and over. That is why the client support interface in DARCA is not a “section in settings”, but a built-in product layer that works constantly and always stays nearby.

Support is доступна in one gesture and does not break context

The main access principle is simple: the user should not think “where is support”. The chat opens from anywhere in the application with a swipe from right to left. This is deliberately done as an overlay, not as a separate page: the user does not lose the context of what they were doing, can immediately show the problem on the current screen, and just as quickly return back. In places where support is especially in demand (transactions, exchange, withdrawal, documents, security), additional quick entry points are available, and in case of errors the system can offer a “smart entry” into the chat exactly by event, so that the conversation starts immediately with a link to a specific operation.

Tip

“One-gesture” entry removes unnecessary navigation, reduces irritation, and decreases the number of requests like “I cannot find where to do this”.

The chat объединяет operation statuses, cases, and documents into a single feed

One of the most common reasons for requests in banks is not the failure itself, but the lack of understanding of “what is happening now”. That is why in DARCA support is built into the status logic: the user has a single event feed where operation statuses, support case statuses, and document statuses are displayed in a clear form. If something is delayed, declined, or requires action, the user sees not an abstract error, but the reason, the current status, and the next step. Thus, a huge class of requests like “where is my money?” and “what is the status of my request?” is closed by the interface, not by messaging.

Note

Rule: if there is a status, the user sees it without asking an operator. Support must reduce the flow of requests, not depend on it.

The answer always ends with an action: deep-links, actions, and documents прямо in the chat

In DARCA, the chat is not a window for instructions, but a control tool. We use action-support: instead of “go to the menu and click”, the user gets a button. Depending on the situation, this can be a deep-link to the required screen or a specific transaction, an action (generate a statement, request a document, create a case), or an in-app confirmation if the step is critical. It is important that the chat can work with documents and files: the user can upload a document directly in the dialogue, receive a certificate or statement, see the verification status, and complete the process without switching to email and without manual forwarding.

This fundamentally changes the perception of service: support does not “explain”, it leads to a result. And the result is always secure: if an action is critical, the final confirmation is done by the user inside the application.

Example

The user asks “how to get a statement”. Instead of instructions, the chat immediately shows a card and a “Generate statement” button, and the result arrives in the dialogue as a file. This saves the user time and reduces the load on support.

There are no dead ends in the system: any scenario has a clear exit

The classic problem of bots is that they either do not understand or send the user in circles. In DARCA this is forbidden at the product level. At any point, the user always has a clear exit: either a solution now (a button or an action), or an operator connection with already collected context, or the creation of a case with a status and expected time. If AI is not sure, it does not “hallucinate”, but routes to an operator or creates a case. If a question requires time, it becomes a case with a status, not a promise “we will check”.

Warning

Zero “empty promises”: if a process is needed, it is оформляется as a case with a transparent status and next steps.

Emergency scenarios without calls: a digital SOS inside the product

Rejecting calls does not mean rejecting fast actions in a critical situation. On the contrary, we move emergency scenarios into a verifiable digital perimeter. In the chat, quick scenarios like “suspected account compromise”, “someone called me claiming to be DARCA”, “I do not recognize a transaction”, “lost my device”, and similar are always available. By selecting a scenario, the user launches a structured chain of steps: session and device checks, security recommendations, actions that can be performed immediately (with user confirmation), and fixation of the status of each stage.

Danger

An emergency situation must turn from chaos into a structured scenario with clear steps and statuses.

A unified communication style and personalization of the assistant tone

For support to feel like a “single system”, we allow configuring the tone of the assistant (strict, neutral, friendly, etc.), and the operator sees these settings and continues communication in the same style. This reduces stress, increases trust, and decreases the feeling of fragmentation between the bot and the human.

The interface is designed with the Messenger Module in mind

We build support from the start so that it can evolve into a future messenger module. Therefore, cards, statuses, documents, buttons, and secure confirmations are designed as universal blocks that today close support needs, and in the future can become part of financial objects in a conversation. This makes it possible to expand the product without rewriting the core logic and without breaking the user experience.

5. Support channels and omnichannel

The user writes where it is convenient, but internally it is always the same case, the same timeline, and unified statuses - without context loss and without risk.

Note

One principle: multiple channels outside - one core inside. This is about convenience, security, and scalability.

We build support so that the user can contact us through a familiar channel, while the internal system remains cohesive and manageable. Externally it looks like many entry points, but internally it is always a single contour: a unified case, a unified timeline, unified statuses, and consistent decisions. In essence, this is Omnichannel, where the channel changes, but quality and logic do not.

Mandatory DARCA channels

The main and priority channel is the In-App Chat. It is embedded into the product, sees full context, can trigger actions and confirmations, and most importantly - it is secure and verifiable. This is our base “correct” channel, because this is where scenarios can be driven to a result, not just conversations.

Rule: if a question is related to money, signatures, or security, the final step always happens in the application.

Additionally, we provide support where users actually live: Telegram, WhatsApp, WeChat, iMessage (and, if needed, regional channels per market). These channels are not for actions, but for quick “on-the-go” contact: hints, explanations, collecting details, sending permissible documents, and sending buttons/links that lead the user to the required application screen via Deep linking.

Tip

Messengers provide speed of entry, and the application provides control and security. Together this solves the problem of “either convenient or secure”.

Unified model “one client - one case - one timeline”

It does not matter where the user started the dialogue: in the application or in Telegram. Inside DARCA it is always:

• one client card
• one active case (or several, if topics are different)
• a unified event timeline where messages, statuses, decisions, document requests, and completed actions are recorded

This delivers a concrete effect: the user does not repeat the problem again, the operator connects and immediately sees what has already happened, and AI works on the full history and does not ask “stupid” questions.

Strict separation of capabilities by channel

To make omnichannel secure, we separate “communication” and “actions”.

In external messengers it is allowed to consult and explain, clarify details and collect information, send instructions and short guides, send documents/files within the case rules, send deep-link buttons to the required application screen, create and manage a case with a status inside our system, and inform about the progress of resolution.

Only in the application, via a button and user confirmation, is the “red zone” located. Neither the operator, nor the bot, nor the external channel performs it:

• any transactions and money operations
• action confirmations
• document signing
• actions affecting security (key settings, access rights, devices)
• any high-risk operations

Principle: the external channel is communication and сопровождение. The application is where actions happen.

Warning

This directly reduces the probability of social engineering: even if an external channel is compromised, it cannot become the “hand” that moves money.

Verification of official channels and protection against impersonation

Since we exclude calls and make messengers an important channel, it is critical to eliminate the “fake support” scenario. Therefore, the application includes a section “Official DARCA Channels” with exact @/ID/account names and instructions on how to verify that it is really us. In messengers we use all available confirmation and verification mechanics (where the platform allows), as well as two-way verification via the application: the bot or operator suggests pressing the “Verify channel” button in the application, and the user receives confirmation that the contact is indeed official.

Routing between channels without context loss

A user can start a conversation in Telegram, continue it in the application, send a document in the application, and receive the final resolution again in Telegram. This is possible due to two mechanisms.

First, identity is linked: the user confirms the binding of the messenger to the DARCA account through the application, after which we know exactly that a specific Telegram/WhatsApp/WeChat belongs to a specific user.

Then the unified case model works: any channel “writes” into the same case, statuses are the same, decisions are the same, and the timeline is one. If a request concerns a critical topic, the system does not try to “perform an action” in the external messenger and sends a “Continue in the application” button. Inside the application, the user sees the context, a summary, a ready confirmation button, and performs the action safely.

How omnichannel works with AI to ensure 24/7 and real languages

AI is the glue layer of omnichannel. The user writes in any language in any channel, AI understands and translates, the operator replies in their own language, AI translates back, and everything is stored in one case and one timeline. It is important that translation is not a separate feature, but a permanent mechanism that makes support global without a global staff.

Why this scheme reduces costs and improves quality

We do not maintain a call center and do not build IVR. We do not hire operators “per language”. We do not lose context and do not get repeat inquiries due to different answers. We move support from “correspondence” to “managed actions”, which reduces resolution time and increases trust.

6. Support AI architecture: 3 layers instead of a “chatbot”

At DARCA, AI is not a single bot, but a permanent system of three interconnected layers: for the user, for the operator, and for quality control.

Info

Important: AI at DARCA works continuously, not “sometimes”. We are building a system where automation delivers results, not an imitation of support.

We do not treat AI as a “checkbox chatbot”. At DARCA, AI is a separate engineering layer of support that works all the time and solves three tasks at once: instantly helping the user, empowering the operator during the dialog, and improving the quality of the service and the product itself after each case. That is why our AI is designed as a system of 3 layers, where each layer is responsible for its own area of accountability and does not replace the others.

Client AI - layer for the user (24/7, scenarios, actions)

The first layer is Client AI. This is the assistant that communicates with the user 24/7 and guides them through clear scenarios, without forcing them to guess what to do next. It can understand complex requests and break them down into steps, but the key point is that it is not limited to “text explanations”. It immediately helps the user reach a result: offers the required actions, provides buttons and deep links, and when needed, requests documents or files directly in the dialog so the process does not have to be taken outside.

Agent Copilot - layer for the operator (context, answers, buttons)

The second layer is Agent Copilot. It runs in parallel while the operator is connecting to the chat and makes support faster without losing quality. Copilot automatically raises the context of the user and the situation, prepares a summary, suggests response options, and most importantly, suggests ready action buttons that help close the case in a single contact. This way, the operator does not waste time searching for information or “manually explaining routes” and brings the user to a solution faster through a clear next step.

Tip

The purpose of Agent Copilot is not to “replace the operator”, but to ensure that the operator enters the dialog already with context, ready solution options, and next actions, closing cases on the first contact.

Supervisor AI - quality control and product development layer (summaries, metrics, improvements)

The third layer is Supervisor AI. It activates after the dialog is завершен and turns support into a mechanism of continuous improvement. Supervisor AI creates a summary of the conversation, evaluates the effectiveness of the resolution, identifies recurring topics and frequent questions, and then helps improve the knowledge base and the product so that many problems do not arise at all in the future. This is critically important: we do not want to endlessly scale support by the “volume of correspondence”, we want to reduce the number of inquiries by improving the interface, statuses, onboarding, and scenarios.

Example

If the same error appears in hundreds of inquiries, Supervisor AI records the pattern, forms conclusions, and turns this into a concrete task: improve the screen, add a hint, change the scenario, or expand the knowledge base so users do not “hit a wall”.

Thus, AI in DARCA support is not a standalone bot, but a system where the user receives real-time assistance and actions, the operator receives acceleration and quality control during work, and the platform receives a continuous improvement loop after each case.

7. Client AI: a 24/7 assistant that drives to results

Client AI is the first level of DARCA support: it works around the clock, understands user context, and guides through safe scenarios with buttons and actions.

Tip

Principle: Client AI does not “write instructions”, it builds a solution route and completes it together with the user.

Client AI is the first layer of DARCA support and at the same time the most massive one. Its task is not to sound “smart” or replace a human with text, but to close the main flow of questions quickly, correctly, and without waiting. The user must receive help at any minute, in any language, and in a single communication style, but most importantly, they must receive not a chat, but a solution. That is why Client AI works as a permanent 24/7 assistant and combines support, product navigation, learning, and action initiation.

Context as a core capability, not an “additional feature”

Client AI lives inside the in-app chat and is available at any moment. It sees the context of what is happening: which screen the user is on, which operation they tried to perform, what the statuses of transactions and cases are, which documents have already been uploaded, and which security settings are enabled. Thanks to this, assistance does not start with “tell me again”, but with facts, and the assistant does not ask unnecessary questions that usually irritate and create the feeling “they are not hearing me”.

Note

The more context the assistant sees, the higher the accuracy of the response and the fewer repeat inquiries.

The response turns into a scenario, and the scenario into the next step

Client AI answers in a way that helps a person understand what is happening and why. But the key difference from classic bots is that it is not limited to an explanation. It translates the request into a clear scenario and immediately shows the next step, because in a financial product an “instruction” rarely closes the problem. The user either completes the action or gets stuck again. That is why the assistant guides them to the result.

Action-support: buttons and deep-links instead of long instructions

Client AI can provide buttons and deep-links to the required screens and specific objects: a transaction, a document, a status, a setting. It can trigger permitted actions such as creating a case, generating a statement, or requesting a document, and also show cards with statuses and next steps. This turns support into a management interface where the user does everything in 1-2 clicks, instead of reading “go there, then there”.

At the same time, we strictly preserve the security boundary. Any actions related to money, confirmations, or signatures are never executed by the assistant itself. It prepares the scenario and displays the button, but the final confirmation is always made by the user inside the application. This protects against errors, fraud, and any social engineering scenarios.

Warning

Client AI can “lead” to a critical action, but it cannot perform it without user confirmation. This is part of the anti-fraud architecture.

Documents and data are requested where the dialogue happens

If data or documents are needed to resolve an issue, the user should not have to go to email, forwarding, or external channels. Client AI requests everything directly in the chat: a document, a photo, a form, a confirmation. It фиксирует the status “waiting”, validates the format, and continues the scenario immediately after receipt. This makes processes short, manageable, and transparent, and the user does not have to “complete a quest” across different channels.

Support as learning: DARCA Academy and the universal assistant

Client AI is not only about solving problems “when something has already broken”. It also works as a universal assistant “for any questions” and as part of DARCA Academy. It can explain features in simple terms, run mini-training on what is available right now, and show what will become available after KYC and how to enable it. It can gently guide the user through gradual onboarding so that the person does not get lost and does not leave due to misunderstanding the product.

Consistent communication style and tone personalization

The assistant supports tone personalization (strict, neutral, friendly, etc.). This is important for trust: the user perceives support as a single system, and the operator (if connected) continues communication in the same style so that the experience does not “break” when switching from AI to a human.

Question

How to avoid the feeling of a “robot” and maintain trust?

Client AI should not pretend to be a human. It should be predictable and useful: respond briefly, show the status, provide the next step, and honestly escalate to an operator when confidence is low.

Escalation without repeats: the assistant passes ready context to the operator

If a request is complex, risky, or the assistant is not confident, it does not argue and does not “guess”. It collects the necessary details, makes a summary, and connects an operator or creates a case. The operator receives already prepared context, so the user does not have to repeat the problem again. In this way Client AI simultaneously reduces the load on support and increases the speed of resolving complex situations.

As a result, Client AI becomes a permanent service layer that makes support instant, safe, and scalable: it handles mass inquiries on its own, and accelerates complex ones through proper routing and context handoff.

8. Eliminating chatbot failures (as in the research)

We remove typical banking bot failures not with “scripts”, but with architecture: context, actions, and safe escalation without dead ends, built into cases and statuses.

Info

In most banks, a “chatbot” is a showcase of automation that irritates users. In DARCA, AI is part of the support platform, connected to cases, statuses, actions, and operators.

The research clearly shows why banking bots are often perceived as a problem: they do not understand complex requests, they do not see context, they ask endless clarifying questions, and when they fail, they turn into a dead end where the user is not given a proper transition to an operator. In DARCA, we eliminate these failures at the system level: our AI is not a separate “bot”, but an engineering layer that always knows what is happening, can guide the user to an action, and can correctly hand off the case to a human.

---

Why banking bots fail and how we address it

Failure No. 1: the bot does not understand a complex request and “breaks”.
The user experiences this as: “I explained the problem, the bot asks strange questions and does not move toward a solution”. We solve this by making AI work not as a guessing game, but as a scenario system: it relies on context (statuses, operations, documents, security, history) and builds the response as a route to the next step. If a request does not fit into a scenario, AI does not “guess”, but switches to an operator or creates a case.

Warning

Forbidden: answering confidently without relying on context and the knowledge base. If confidence is low - only handoff or a case.

Failure No. 2: the bot has no context, and the user is forced to repeat everything from scratch.
A classic pain point: “I explained it to the bot, then an operator connected - and I have to tell everything again”. This is impossible for us, because communication always lives inside a case entity, and before connecting an operator the system generates a summary, a list of related objects (operation, document, module), the current status, and the next step. The operator connects already “inside the situation”.

Failure No. 3: the bot turns into a dead end.
When the bot does not help and there is nowhere to go next, the user gets angry and leaves. In DARCA, there are no dead ends: at any moment there is a clear exit - a solution via a button, connecting an operator, or creating a case with a status.

Failure No. 4: the bot cannot do anything, it only talks.
If the bot answers with text and the user still has to manually go through a complex path, that is not support. That is why our chat is an action-chat: help ends with an action (a button, a deep link, a document request, generating a statement, creating a case), not with a long instruction.

---

Three mandatory properties that remove the “annoying bot experience”

To prevent failures from repeating, support must have three properties at once, and all three are mandatory.

1) Context
AI sees the history of requests, operation statuses, documents, security events, active modules, and the user’s actions in the app. This makes answers accurate and reduces unnecessary clarifications.

2) Actions
AI can provide buttons and deep links, start Workflow processes, request documents, and generate documents (statements, certificates) directly in the chat.

3) Handoff (escalation)
AI can connect an operator with a ready summary, route the case to the correct queue, set priority, and фиксировать the next step, so the operator does not start “from a blank page”.

Tip

Together, these properties remove the key pain point: the user is not “chatting with a bot”, they are following a solution route.

---

Confidence boundaries: when AI solves it itself, and when it switches to a human

We are not building a robot that stubbornly argues with the user. We are building a system that knows its boundaries and acts rationally.

AI solves it itself when the request is standard, clear, low risk, and AI has enough context and a ready scenario with a button.
AI connects an operator when the request is complex, non-standard, the user asks for a human, there are signs of high risk (security, fraud, disputed operations), or a responsible decision is required.
AI creates a case with a status when the problem cannot be solved “immediately” and a verification process is needed (compliance, verification, investigation), or additional documents and steps are required.

Principle: if it cannot be solved instantly, the user must see a status and understand what is happening.

---

”Learning from the operator’s choice”: how AI gets better every day

It is important to us that AI improves not “in theory”, but on real cases. For this, AI suggests several response options to the operator, plus proposed actions and buttons. The operator selects the best option, edits it, or writes their own, and the system records the choice, the edits, and the result (whether the case was closed, whether there was a повтор, the customer rating). This allows us to improve the quality of answers, expand scenarios, reduce the number of escalations, and increase First call resolution.

---

How we eliminate “annoying” bot patterns

We ban typical “sins” of banking bots and close them with system rules.

• Endless clarifications without results - if there is no progress after N steps, AI must offer an action or a handoff.
• Off-topic answers - AI must rely on context and the knowledge base, and if it is not sure, it must not invent, but escalate.
• Hidden support - support is always available, not hidden in menus and does not require “calling through”.
• Shifting responsibility to the user - instead of “ensure, check, contact”, we give a button and lead to a solution.

---

What the user gets in practice

At the level of perception, support looks like this: the user writes once, gets a clear explanation, sees a status, gets a button, gets a result. If needed, an operator connects, but already with an understanding of the context. If the process is long, there is a case, statuses, and timelines. This is exactly how we turn AI from an irritant into a key driver of better service.

9. Full rejection of IVR and calls as a product strategy

We remove calls and IVR not for the sake of “hype”, but as a practical anti-fraud strategy: less fraud, more transparency, faster service, and simpler global scaling.

Warning

DARCA rule: we do not make calls and we do not accept calls. Any “call from DARCA” should be considered fraud.

We deliberately remove phone calls and IVR from customer service. This is not a debate about “which channel is more convenient”, but an engineering decision that simultaneously reduces fraud, increases transparency, makes service faster, and simplifies scaling worldwide. It is important that we did not just “remove calls”. We replaced them with a system where any request becomes a manageable digital case with a status, and critical steps are performed only inside the application with user confirmation.

Why IVR breaks service and why we exclude calls

Phone trees and IVR almost always create friction. The user wastes time on “press 1, press 2…”, then is forced to repeat the information several times, and the conversation itself does not preserve context as a digital case. As a result, quality and outcome depend on who the person gets connected to, meaning the service becomes a “lottery”.

But security is even more important. The phone is the main tool of fraudsters and Social engineering. A typical real-world scenario is well known: a fake number, “bank security service”, psychological pressure, requests to name a code or phrase, or to “confirm the cancellation of a transaction”. Calls have no built-in, natural verification mechanism, which makes them ideal for attacks.

Finally, the phone scales poorly. To maintain high-quality voice service, you need a huge staff, many shifts, separate quality control, and constant training. This is expensive, slow, and in the end still does not provide what digital support does - statuses, auditability, and process reproducibility.

Note

Rejecting calls is a way to turn support from a “conversation” into a manageable process with transparent rules and verifiable actions.

How we replace the phone: chat routing and emergency scenarios in chat

Instead of IVR, we run chat routing. The user writes one request in any language, AI performs Triage, and the system immediately leads through a scenario and provides action buttons. If necessary, 1-2 clarifying questions are asked, but without a “labyrinth” and without endless transfers between categories.

Since there are no calls, emergency scenarios must be built into the product. Therefore, the chat always has quick buttons:

• “Suspicion of account compromise”
• “I was called by DARCA”
• “I do not recognize a transaction”
• “Problem with access”
• “I need to urgently stop a risk”

Clicking them launches an “emergency flow” inside the chat: checking active sessions, logging suspicious events, security recommendations, and fast safe actions that the user confirms. The point is not to scare the person, but to give them an instant, manageable scenario that actually reduces risk.

For critical steps, a separate rule applies: we do not “perform actions” in a messenger. We provide a “Continue in the app” button, and the user confirms the critical step inside DARCA. This way support remains convenient, but critical actions stay within the protected application perimeter.

Tip

As a result, any risk scenario turns not into a conversation, but into a set of verifiable steps that cannot be “talked into” by voice.

Continuous education: “if they call from DARCA, it is 100% fraud”

For the “No Calls” rule to actually work, it must be закреплено in the interface and in user habits. We embed it immediately into several touchpoints: in the profile and security settings as a separate block “DARCA never calls”, in the initial onboarding as a short warning (without fear-mongering, but clearly), in the support chat as a quick scenario “I was called” with explanation and actions, and in the Academy as a lesson “how to recognize fraud”.

When a user writes the phrase “I was called”, the system reacts not like a “phone operator”, but like an anti-fraud mechanism: AI immediately recognizes the risk, activates a protective scenario, and offers actions - check logins, change security settings, limit operations, and create a case.

“Suspicion of compromise/fraud” button and protective actions

The protective scenario is triggered by several signals: a message “I was called”, “I was robbed”, “money was withdrawn”, “suspicious transaction”; a login from a new device; an attempt to change critical settings; any behavioral anomaly detected by the system.

Next, the scenario does not “promise help”, but performs concrete steps that the user sees and confirms:

• “Check active devices/sessions”
• “Terminate all sessions except the current one”
• “Strengthen confirmations” (step-up)
• “Temporarily limit operations” (with user confirmation)
• “Create a priority Sev-1 case”
• “Connect an operator” (if the risk is high)

This is better than a call because it is instant, confirmed by the user inside the application, has auditability and statuses (transparent Audit trail), and eliminates voice-based social engineering.

Example

The user writes “I was called by DARCA, they said I urgently need to cancel a transfer”. The system does not argue and does not ask unnecessary questions: it activates the protective scenario, shows active sessions, offers to terminate unnecessary ones, strengthen confirmations, and temporarily limit operations, then creates a priority case. Everything happens inside the product and is фиксируется by statuses.

Why “No Calls” increases trust rather than reduces it

Intuitively, it seems that “without a phone” will feel less trustworthy. In practice, the opposite works, because trust is built on predictability and verifiability. With “No Calls”, support is always available (24/7 chat), responses are fast (AI), solutions are concrete (buttons and actions), critical steps are safe (user confirmation), and everything is transparent (statuses and cases). The user stops depending on “getting lucky with an operator” and starts living in a model where “everything is verifiable and manageable inside the product”.

10. Onboarding and complex processes as workflows

We design onboarding and any “long” scenarios as managed workflows with statuses, progress, action buttons, and secure confirmations.

Note

The most expensive cause of “bad service” is not operator responses, but processes without status: the user completes a step, then silence, and leaves because “nothing is happening”.

In DARCA, onboarding and all complex support scenarios are built not as a set of forms and text instructions, but as managed workflows - processes that lead to a result and preserve state at every step. This means the user always understands where they are, what is happening right now, and what the next step will be. They do not “fall into a labyrinth” and do not depend on whether an operator is online. They go through a route where every stage has a status, a reason (if something is delayed), and an action button.

Why onboarding and “long” cases break in banks

Usually, failure happens not because of missing features, but because of a lack of transparency. The user is given many steps and forms without explanation, then asked for documents, then “checks” begin, but the person does not see a status, does not understand timelines, and starts to get nervous. If they get distracted or close the app, progress is lost, and it feels like they must start over. Minor errors in documents lead to repeated submissions, and support turns into endless messages like “send it again” instead of a clear process.

Warning

Onboarding is the user’s first experience and part of the customer service. If it looks like bureaucracy without status, the user perceives the product as unreliable.

How this works in DARCA: a process with stages, status, and the next step

We build onboarding and complex cases as a workflow with stages: profile creation, basic checks, document request, document submission, verification, result confirmation, enabling the required capabilities. But what matters is not the sequence itself, but how it feels. At every stage, the user sees progress, the current status, and the next step. If there is a delay, the system shows the reason in human terms (without exposing internal mechanics, but also without “we will not say anything”). If additional information is needed, it is requested immediately and in the correct form. If a step is completed, it is visible. If a step is in progress, it is visible. If a step requires action, it is visible and is always accompanied by a button.

Onboarding through chat: a chat-guided approach instead of “fill in the form”

The key element is the in-app chat as the interface for managing the process. The user is not left alone with a form. The chat explains the steps briefly and to the point, shows the verification status, provides a “continue” button, requests documents directly in the dialog, and prompts how exactly they should look. This makes onboarding “guided”, not a “quest”. This significantly reduces the percentage of abandoned registrations and decreases the number of support requests, because most questions are resolved by the process interface itself.

Tip

If a person at any moment understands “where I am now” and “what’s next”, they rarely write to support. A workflow is a way to reduce service load not by the number of operators, but by process clarity.

Documents and corrections: not “rejected”, but a clear reason and an “fix” button

Documents are one of the most frequent pain points in fintech. We solve this by making every document request structured: what is needed, why it is needed, what format is required, and what common mistakes look like. After submission, the user sees the status “accepted / under review / needs correction”. If a document does not fit, the system does not just say “rejected” without explanation, but shows the specific reason and provides a button “fix” or “upload again”. And all of this happens within the same workflow and the same case, not in fragmented chats.

Long support cases also become workflows: disputes, checks, recovery

In exactly the same way, we build workflows for situations that cannot be “closed with a single answer”. For example, if a user writes “I do not recognize this transaction”, this is not a chat exchange, but a process: event фиксация, linking to the transaction, collecting details in chat, protective measures with user confirmation, investigation, and the final decision. In compliance scenarios (KYC/AML), we avoid silence: if an operation is stopped for review, the user sees the status “under review”, understands what exactly is required (for example, a document or a confirmation), can send it immediately in chat, and receives updates as the process moves forward. In access recovery, everything is also turned into a process with stages and status, not into “waiting for a call”.

Info

We rely on the principles of Know_your_customer and Anti-money_laundering, but we build communication so that the user always has a status, a reason, and the next step.

“Log in and continue”: the user does not lose progress

One of the key mechanics of a workflow is state persistence. The user can close the app, come back in a day or a week, and continue exactly from the step where they stopped. On return, the system shows a short summary: “You stopped at step X. The next step is Y” and provides a “Continue” button. This looks simple, but it is exactly what turns a complex process into a feeling of control and predictability.

Why this reduces support load and increases trust

When processes are built as workflows, support stops “untangling chaos” and starts managing clear cases. There are fewer repeated inquiries like “what is the status”, fewer errors, fewer lost documents, fewer discrepancies between the operator and the system. The user gets an experience where everything is transparent: the process is alive, it is moving, and there is always a next step. This increases trust and makes the service scalable without inflating headcount.

Ultimately, the workflow approach ties chat, statuses, cases, documents, and confirmations into a single system: chat becomes the interface, the case becomes the container, the workflow becomes the process, the status becomes transparency, buttons become actions, and user confirmation becomes security. This is how onboarding and complex processes turn from “bureaucracy” into a predictable path to a result.

11. DARCA Academy (learning as part of the service)

Academy is a layer of knowledge and actions: it educates users, reduces support load, and increases onboarding conversion through scenarios and buttons directly in chat.

Info

The best service is not only “responding quickly”, but reducing the number of errors and questions, and if they do arise - bringing the user to a result through context and actions.

We build DARCA Academy as a full-fledged part of the service, because in a financial product “support” starts long before a user contacts an operator. Most irritation and loss of trust are born not at the moment when the user writes to chat, but earlier: when they do not understand what to do, make a mistake, get confused in the interface, do not see a status, are afraid to click “the wrong thing”, and postpone using the product. Therefore, for us Academy is not “a section with articles”, but a living knowledge layer, embedded into the product and chat, that teaches, guides, and helps complete actions.

Academy does not just explain, it guides and brings to a result

Classic knowledge bases are often useless because they give text but do not give the next step. DARCA Academy is structured differently: any material does not end with “read and figure it out”, it ends with a clear action. If a lesson explains how to enable a module, there must be a “Enable module” button next to it. If a lesson is about verification, there must be a “Start KYC”, “Upload document”, “Check status” button next to it. In this way, knowledge becomes part of the interface, not a separate archive.

Warning

Rule: knowledge without actions is not a service. Academy is always linked to buttons, deep-links, and scenarios.

What formats we need and why there are several

Academy covers different levels of user “readiness”. Some people need a short 30-second hint, some need a step-by-step scenario, and some need a mini-course to feel confident. Therefore, we use several formats, but all of them follow one principle: quickly give understanding and lead to the next step. These can be short instructions, guided flows, checklists, mini-lessons and courses, as well as FAQ, which in DARCA becomes not just “question-answer”, but “question-answer + action”. At the same time, any technical or process term remains transparent and explainable, and links and wording rely on clear standards, for example FAQ and Deep_linking.

AI uses Academy as the official knowledge corpus

For support answers to be consistent and predictable, AI must not “explain however it wants”. It must rely on the official knowledge corpus. Therefore, Academy materials become a source of truth for AI: the assistant can give a short excerpt, attach the needed lesson, guide the user through steps directly in chat, and, importantly, display action buttons so that the person does not get lost in the text. This increases accuracy, reduces the number of errors, and makes the experience the same regardless of time of day and language.

Note

Academy turns AI answers from “text” into scenarios with clear actions and statuses.

Contextual learning: “teach exactly when it is needed”

We do not force the user to “go learn separately”. Academy works contextually. If the user is stuck at a verification step, chat will offer the corresponding mini-lesson and a “continue” button. If a person makes an exchange for the first time, the system will explain how the final amount is formed and give a “view transaction details” button. If the user writes “how to enable business features”, AI will not just throw a link to an article, but will guide them through a scenario with a checklist and actions. This is how learning becomes part of the service, not “documentation for the sake of documentation”.

Why this reduces support load and increases conversion

When the product explains itself and guides the user along the route, the number of inquiries like “where to find this” and “how to do this” drops sharply. The operator connects only where responsibility, a non-standard solution, or high risk is needed. In addition, Academy strengthens onboarding: steps become clear, statuses transparent, document requirements explained in advance, and errors corrected through a “fix” button instead of endless back-and-forth. This reduces “abandoned registrations” and increases completion of key scenarios, including Know_your_customer and processes related to Anti-money_laundering.

Academy as a trust tool, not only “learning”

A user trusts the service when they understand what is happening, why it is happening, what options they have, and that they control the situation. Academy makes the product explainable and predictable, and therefore increases trust and retention. This is especially important in crypto and fintech products, where fear of making a mistake is often stronger than interest in new capabilities.

How Academy stays relevant

So that Academy does not turn into an “archive of articles”, we manage it as a product: materials have versions, are linked to actions and scenarios, and update priorities are driven by data. Supervisor AI captures the top recurring questions and the points where users most often “get stuck”, after which we update lessons, add new scenarios, and improve the interface. This way Academy becomes a living mechanism for service improvement that strengthens AI, reduces load on the team, and makes the user experience increasingly clear.

Question

How do we make sure that knowledge does not become outdated?

Manage Academy as a product: versions, linkage with buttons and scenarios, prioritization of updates based on support data and user behavior.

As a result, DARCA Academy achieves three key goals at the same time: it reduces the number of errors and questions, speeds up support through ready-made scenarios, and increases trust because the product becomes understandable and manageable at every step.

12. Universal Assistant (any question) + built-in scenarios

The DARCA chat becomes a universal interface: it answers any questions, but when queries are about the product it always turns the dialog into concrete actions through statuses, cases, and buttons.

Tip

We turn the chat from “a place you write to when something goes wrong” into a universal interface that the user gets used to accessing every day.

We want the DARCA chat to be not a “support chat”, but a universal interface that the user gets used to using constantly. The more often a user interacts with the assistant, the fewer mistakes and misunderstandings there are, the higher loyalty and retention become, the easier it is to guide complex processes (onboarding, KYC, settings), and the faster product-related questions are resolved.

Therefore, we introduce the Universal Assistant module: the user can ask any question - from banking-related to everyday. At the same time, the assistant always knows how to turn the conversation into an “action” if the question is related to DARCA.

---

Modes: Questions about DARCA and questions about “everything”

So that universality does not turn into chaos, we split the assistant’s work into two logical modes (for the user it looks like a single chat, but internally the system understands the context).

DARCA mode

This includes questions about the product and features, transaction statuses, documents, modules, verification and onboarding, security, portfolio, and finances inside DARCA. In this mode, the assistant responds not abstractly, but based on platform data and built-in scenarios, so that the user immediately reaches a result.

Universal mode

This includes general knowledge (for example “when was Clinton born”), weather, reference data, and explanations of any topics (finance, technology, travel, everyday questions, etc.). This is done for two effects: the user gets used to the idea that “DARCA is always nearby and helps”, and the chat becomes a natural interface rather than “a place you only write to when something is wrong”.

Note

“Universal” is needed not for “small talk”: it creates a habit of using the chat every day, and therefore increases retention and reduces the number of mistakes in the product.

---

Embedding into the chat: command → answer → buttons and actions

The key principle of the universal assistant: if the question is related to the product or the user’s finances, the assistant must turn the answer into a concrete action.

How the assistant understands that a question is “about the product”

There are markers by which the system recognizes product context: mention of a transaction, amount, date, merchant; phrases like “why did the transfer fail”, “where is the money”, “why was it held”; questions like “how to connect a module”, “how to make an exchange”; commands like “show balance”, “show portfolio”.

In these cases, the assistant does not limit itself to text. It attaches a status or a object (transaction or case) to the answer and gives buttons “Open”, “Check”, “Generate”, “Confirm”, “Continue”.

Behavior examples

• User: “Where is my transfer?”
  Assistant: briefly explains the situation, suggests “Open transaction status” and provides the option “Create a case if delayed”.

• User: “What is the weather in Tbilisi tomorrow?”
  Assistant: answers in universal mode. If the user adds “remind me to take an umbrella in the morning” - the assistant creates a task (Autopilot).

• User: “When was Clinton born?”
  Assistant: answers in universal mode. If the user says “save this date as…” - it creates an event at the user’s command.

---

Quality control and prevention of factual errors

The Universal Assistant must be not only useful, but also high-quality, especially when it comes to facts.

Fact checking in universal questions

For general knowledge, we use a verification mechanism so as not to produce a “confident mistake”. When necessary, the assistant confirms facts with sources, and in disputed questions it provides multiple sources or explicitly states uncertainty.

Internal “truth” for DARCA-related questions

For questions about the product, statuses, and processes, the assistant answers based on the knowledge base (Academy/KB), platform statuses and data, cases, and workflows. This eliminates the situation where “the assistant said one thing, but the system does another”.

Warning

For product questions, the principle of a single source of truth applies: answers must match how the platform actually works and which statuses are available to the user.

---

Universal Assistant as a retention and service tool

If a person uses the chat only when there is a problem, the chat becomes associated with negativity. If a person uses the chat daily (questions, tasks, portfolio, reminders), the chat becomes a “home”.

The more often a user interacts with the assistant, the faster they understand the product, the fewer mistakes they make, and the fewer stressful situations they face. And complex processes (verification, KYC, onboarding, documents) are easier to go through when there is an assistant nearby who explains, shows status, and provides buttons.

---

Linking the Universal Assistant with Academy and Support Core

The Universal Assistant does not exist in isolation. If the question is “how to do”, the assistant uses the Academy (a lesson or a scenario) and provides action buttons. If the question is a “problem”, the assistant creates a case in Support Core, shows the status, and the next step. If a question is repeated often, Supervisor AI records it and triggers improvements to the product and the knowledge base.

This is how the universal assistant becomes part of our best-service system, rather than “just chatter for the sake of chatter”.

13. Personal Finance Autopilot - reminders, transaction search, tasks

Autopilot helps the user not only “when a problem has already happened”, but prevents it in advance: it recognizes financial patterns, finds transactions in human language, and launches useful automations.

Example

Instead of thousands of identical requests like “I forgot to pay” or “find the payment” - Autopilot makes this part of the product and reduces stress, errors, and the load on support.

We want DARCA to help the user not only at the moment when “something went wrong”, but earlier - at the point where the problem has not yet happened. This directly increases service quality: the more we prevent forgotten payments, confusion in transaction history, and loss of context, the fewer negative requests we get, and the higher trust and retention become.

Autopilot is a module that uses our AI and access to user data to recognize patterns of spending and payments, remind and suggest actions, answer questions about transaction history, execute scheduled tasks (digests, asset rates, etc.), and turn important events into convenient “tags” and reminders.

---

Smart reminders based on recognized transaction patterns

One of the most frequent sources of irritation is recurring payments: rent, mobile service, utilities, subscriptions. Autopilot builds a “regularity map” and helps the user without manually setting up each reminder.

How Autopilot understands that a payment is recurring

We determine regularity based on signals:

• recurring recipient/merchant
• similar amount or range
• periodicity (month/week/quarter)
• similar purpose
• recurring categories (rent, utilities, mobile service, subscriptions)

Based on these signals, Autopilot forms a “recurring payment candidate” and then acts according to the rules:

• if confidence is high - it starts suggesting automatically
• if confidence is medium - it уточняет with the user in chat (“this looks like a recurring payment, enable reminders?”)

This way we avoid unnecessary noise while preserving maximum usefulness.

What a reminder looks like

A reminder is not just “text”. It is a card with buttons:

• “Pay now”
• “Remind tomorrow / in 3 days”
• “Change reminder date”
• “Disable reminders for this payment”
• “This is not a recurring payment” (so that Autopilot does not make mistakes going forward)

If a payment requires a critical action - the button leads to the app, and the user confirms the payment there.

Reminders as the date approaches

If we see that rent is always paid, for example, on the 1st-5th:

• we remind in advance (for example, 2 days before)
• at the same time we take user behavior into account (if they always pay on the 3rd - we adapt)

---

Transaction search in “human language”

One of the strongest Autopilot features is the ability to search for transactions the way a human thinks, not the way a banking system requires. The user should not have to remember the exact date, category, or merchant wording to find the needed payment.

Tip

Natural language search in finance reduces frustration and saves time: the user asks a question as usual, and the system builds the filters itself.

Examples of user queries

• “A month ago I bought flowers, remind me of the date”
• “How much did I spend on taxis last week?”
• “Find a transfer where it was 300 dollars, I think in October”
• “Show all payments for the apartment for the last 6 months”
• “When did I last pay for mobile service?”

How we solve this

Autopilot:

• understands the meaning of the query
• filters transactions by time/amount/category/merchant
• returns the result:
  • date
  • amount
  • recipient
  • link to the transaction
  • and, if needed, a “show details” button

Extending the result into an action

If the user asks “remind me of the date”, we can immediately suggest:

• “Add to events”
• “Set a reminder a year ahead”
• “Save as a tag”

This turns “search” into a useful automation.

---

Personal events and the user’s “memory”

Users often associate expenses and payments with life events. We turn this into product value: the user assigns meaning to transactions themselves, and Autopilot helps preserve this meaning and return to it.

Example: “this was the day of the first date”

User: “A month ago I bought flowers, find the date. Remember it as the day of the first date.”

Autopilot does:

• finds the transaction
• extracts the date
• creates the event “First date”
• offers options:
  • “Remind every year”
  • “Remind a week before the date”
  • “Add a note”
  • “Attach a photo/place” (if needed)

Events as part of the chat

Events become available through the chat:

• “what is the date of the first date?”
• “when did I buy the ring?”
• “when was the first rent payment?”
  etc.

---

Scheduled automations: digests, rates, reports, notifications

Autopilot can work as a “schedule assistant” that proactively brings the needed information without user requests, while always remaining manageable and transparent.

The user sets tasks in the chat

The user can simply write:

• “Send me the rates of all cryptocurrencies in my portfolio every morning”
• “Every Monday send weekly expenses”
• “Every day at 21:00 show the balance and changes”
• “Once a month send a subscriptions report”
• “If an asset’s rate drops by X% - notify me”

Autopilot turns this into a task:

• saves the schedule
• the data source (portfolio, transactions)
• the message format
• the delivery channel (in-app / messenger, if allowed)

Digests must be short and useful

We do not make “a wall of text”. We make cards:

• “portfolio: changes”
• “main expenses”
• “expected payments”
• “suspicious events”
  and “view details” buttons.

---

Automation center: managing tasks and execution history

If the user has many tasks (“every morning”, “every month”, “remind me”), they need control. That is why a section appears in the app:

• list of all active automations
• on/off toggles
• time and frequency settings
• execution history (“when it was sent, what was sent”)
• quick buttons “pause for a week”, “change schedule”

Rule: the user always has control and transparency - what Autopilot does and when.

---

How Autopilot reduces the load on support and improves service

Autopilot removes a huge class of requests:

• “I forgot to pay”
• “I do not understand when I paid”
• “find the payment”
• “why was it charged”
• “where is my document/statement”
• “remind me”

And most importantly - it turns DARCA into a familiar daily tool, not an app “for when there is a problem”. And this is the strongest thing you can do for retention and trust.

14. Operating model: a small team you can trust

DARCA support scales globally through AI, strict regulations, and on-call for critical cases, maintaining speed, security, and quality without a huge staff.

Info

We build support 24/7/365 and in all languages, but without an “army of operators”: scale is delivered by AI, while trust and responsibility are held by a small team.

We design support as a system, not as a “call center”. In traditional banks, service quality often depends on headcount, shifts, queues, the human factor, and inevitable differences in operator skill levels. At DARCA we do it differently: speed and availability are provided by the AI-first layer, while complex and critical situations are handled by a small, well-trained, and fully controlled team. This approach allows us to simultaneously maintain quality, security, and scalable economics.

AI-first line: instant response, unified standard, any language

The first contact in support must always be fast, and responses must be consistent and predictable. That is why our first level is built around AI. It handles the typical flow: explains features, helps find the right screen, shows transaction statuses, guides onboarding scenarios, attaches Academy materials, performs routing, and instantly switches to the user’s language. Importantly, AI does not respond “however it feels”, but based on the knowledge base and internal scenarios, so the service does not depend on the time of day or the random “quality of a shift”.

Note

AI provides scale, but it does not receive the authority to “take risks”. Any critical actions remain with the user through confirmation in the app.

Small L2/L3 team: solving the complex, not “explaining the obvious”

Where responsibility, a non-standard solution, or human involvement is required, the second level connects - a team of experts. Their task is not to retell instructions, but to bring cases to a result. And the third level consists of narrow specialists who are engaged selectively: complex investigations, rare incidents, subtle compliance situations, critical errors. We deliberately do not grow a “mass workforce”, because mass inevitably increases errors and risks. Instead, we build a support “special forces” unit that can be quickly trained, controlled, and trusted.

24/7 without a huge night shift: on-call only for Sev-1

Round-the-clock operation usually means large shifts and high costs. We achieve 24/7 through a different logic: AI is always present and handles the main part of requests, while on-call works for critical cases. This means we wake a human only when the system has automatically recognized a truly high priority, not because the user does not have an answer “right now”. At the same time, AI and the platform themselves understand what is considered critical (Sev-1), whom to escalate to, which data to attach to the case, and what next step to give the user so that they do not remain in uncertainty.

Tip

The user should not have to “fight” for priority. In critical situations, priority is assigned automatically, and communication always remains transparent through statuses and the next step.

Authority without risk: the operator helps, but cannot “break security”

Our model is built on strict separation. An operator can help, accelerate, and сопровождать: request documents, issue certificates, explain statuses, send the user the correct deep-links and buttons. But any actions that create financial, legal, or reputational risk are not done “manually from the chat”. They are performed only through user action in the app, confirmation, step-up verification, and audit. This protects both the user and us: it eliminates human error, abuse, and “social engineering via support”.

Playbooks and checklists: turning rare situations into managed processes

For a small team to be strong, decisions must be standardized. We use playbooks - regulations and checklists for key case types. Each playbook describes the signs of a problem, fast triage, a step-by-step solution, escalation rules, and which buttons or actions to give the user. This turns complex and rare cases from “improvisation” into a predictable process that works equally well regardless of who opened the case.

Warning

Any support without regulations eventually becomes a lottery. Playbooks make the service reproducible and protect reputation.

Quality control and training: AI copilot and Supervisor AI

We accelerate the team’s work with two layers. The first is the AI copilot, which suggests answers, steps, and the required materials to the operator, reducing resolution time and lowering the risk of error. The second is Supervisor AI, which creates dialogue summaries, evaluates quality, identifies recurring problems, and points out where playbooks, Academy, or the product need improvement. As a result, support becomes a self-tuning system: the more it works, the fewer errors there are and the higher the speed.

Why this model is economically stronger and feels more premium

This operating model makes the service “premium” not because it is expensive, but because of its architecture. AI handles mass volume and languages, a small team solves complex and critical cases, 24/7 is achieved via on-call, processes are standardized, and quality is controlled automatically. As a result, the user gets a fast response, a clear status, and the next step, while we get support that scales globally without an explosion of costs and without compromising security.

15. Metrics, SLA, and Quality Control

We manage support as a product: through metrics, SLA, and quality control, so that the service is predictable and scales without losing its level.

Info

The best service is not “it seems to have become better”, but a measurable system, where quality, speed, and the reasons for dissatisfaction are visible at any moment.

The best service is not “it seems to have become better”, but a measurable system, where at any moment we can see:

• what is happening with quality
• where problems are emerging
• how effectively AI is working
• how quickly cases are being resolved
• where users are dissatisfied and why

With numbers, we manage the service as a product: we do not “treat symptoms”, we find and eliminate root causes. This gives early signals of degradation, allows us to maintain stable quality as the user base grows, and to sustain the level of service expected from the best neobank in the world.

Note

Metrics for us are not a “check-the-box” report, but a management system: see - explain - fix - confirm improvement in the data.

How this works in practice

We collect indicators into a single quality control loop: by channels, case categories, languages, regions, and product areas. It is important that we evaluate not only “how much we responded”, but also “how the case ended” - with a resolution, a repeat request, an escalation, a delay, or dissatisfaction.

The key point: if somewhere the load “swells” or quality drops, the system must show this quickly and precisely - with linkage to root causes and case types. Then improvements are made in a targeted way: through the product, the knowledge base, scenarios, risk rules, or changes in operator and AI behavior.

16. Support Service Architecture

Support in DARCA is part of the platform architecture: it grows together with the product, does not break the core, and scales through a modular approach and observability.

Info

We build Support not as a “separate department”, but as an architectural layer of the platform, so that scaling does not turn into chaos.

We build customer service not as a “separate department”, but as part of the DARCA platform architecture. This is critical because:

• functionality will grow (many modules, many scenarios),
• technologies will change rapidly,
• we need to be able to add new capabilities without rewriting the entire product,
• users do not need all functionality at once - they enable only what they actually need.

Therefore, our service architecture is built on the principle of Core + Modules: there is a stable core, and there are connectable modules that extend functionality.

---

Support as the default module of the platform + extensions as connectable modules

The base layer that everyone has

Every user always has the base service layer enabled:

• in-app chat (1-gesture access),
• case creation and statuses,
• basic support scenarios,
• security of the support channel (no-calls, critical action confirmation),
• basic AI (answers + routing + buttons).

This is the “default”: without it, the product simply does not exist.

Note

The base layer is the minimally sufficient support that is always available and always the same in quality, regardless of region and time of day.

Extensions - at the user’s choice

Then functionality is expanded through modules:

• DARCA Academy (learning, scenarios, guides)
• Universal Assistant (any question)
• Personal Finance Autopilot (reminders, tasks, transaction search)
• Messenger Module (evolution of chat into a messenger with financial functions)
• Business modules (corporate support and document workflow scenarios)
• Security tools (advanced protection modes)

Principle: the user enables only what they actually need. This reduces interface overload and simplifies product scaling.

---

Core + Modules: how we add new capabilities without “breaking the core”

Support Core (the core)

This is the immutable core that provides the foundation:

• Case Management (cases, statuses, SLA)
• Omnichannel (a single timeline)
• Document workflow in chat
• Audit and action log
• Security policies (critical actions only via confirmation)
• Integrations with the product core (operation statuses, events)

Support Core must not depend on the UI or specific messengers. It must be stable and extensible.

Experience Layer (interface layer)

These are the “storefronts” of the same core:

• in-app chat,
• messenger channels,
• (in the future) a full messenger inside the app,
• operator admin panel.

Any new channel does not require rewriting the core - it simply connects to it.

AI Layer (intelligence layer)

AI is connected to the core and the knowledge base, and works at all levels:

• user assistant,
• operator copilot,
• Supervisor AI.

AI is also modular: we can improve models, change components, and add new scenarios without breaking the foundation.

Modules Layer (connectable products)

Each module:

• has its own functionality,
• its own scenarios,
• its own UI elements,
• but relies on the shared core services:
  • cases,
  • statuses,
  • action buttons,
  • confirmations,
  • document workflow,
  • events.

Result: a new module = new value without rewriting the platform.

---

Integrations: payments/risk/KYC/docs/ledger/notifications

Support becomes truly effective only when it “sees” the product and can accompany user actions through statuses, documents, and risks, rather than just exchanging text. Therefore, we build integrations as part of the Support Core.

Payments / Transfers / Exchange

• real-time operation statuses,
• the ability to open a transaction from chat,
• buttons “check status”, “create case”.

Risk & Anti-fraud

• triggers “suspected account compromise”, “suspicious transaction”,
• protective scenarios in chat,
• restrictions and step-up confirmations (via button and user confirmation).

KYC / Compliance workflows

• transparent verification statuses,
• document requests directly in chat,
• continuation of the process “from the same step”.

Docs & Sign

• statements, certificates, confirmations,
• signatures (only via user confirmation),
• storage of statuses and issuance history.

Ledger / Portfolio

• portfolio and asset context for user queries,
• Autopilot digests and reminders,
• transaction search.

Notifications

• notifications about case statuses,
• notifications about operation statuses,
• Autopilot reminders.

---

Support reliability and observability (traces/metrics/logs)

Observability

We build the system so that we can see:

• what exactly is happening with requests,
• where speed drops,
• where errors have increased,
• where AI has started performing worse.

We need:

• dialogue logs (internal),
• case events,
• SLA metrics,
• AI metrics,
• tracing of key scenarios (workflow, document issuance, confirmations).

Tip

Observability in support is a way to keep quality predictable: we see degradation earlier than users feel it at scale.

Load resilience

The support must be able to withstand the peaks:

• mass campaigns,
• user growth,
• waves of requests during incidents.

For this:

• AI offloads humans,
• cases and statuses work as a queueing system,
• critical issues (Sev-1) have a separate routing path.

Degradation without “collapse”

If part of the systems is unavailable, support must not “die”. For example:

• if some statuses are temporarily unavailable, chat still works and creates cases,
• if operators are overloaded, AI still responds and guides users through scenarios,
• the user always sees that the request has been recorded.

---

We take into account that technologies change quickly - therefore the architecture must be flexible

We design DARCA in advance so that:

• AI components can be replaced without rewriting the Support Core,
• new communication channels can be connected,
• new modules can be added,
• new products can be released quickly.

This is our strategy: not to tie ourselves to a single technology forever, but to build a platform that can rapidly evolve together with the market.

17. Service security and risk control

Support is the attack surface of fintech, so we design it as a protected perimeter: rules, constraints, confirmations, audit, and risk scenarios.

Warning

Customer service is one of the most attacked areas in fintech: fraudsters benefit from bypassing protections through emotions and social engineering. For us, support is not a weak link, but an additional layer of protection.

Customer service is one of the most attacked areas in fintech, because fraudsters benefit from “bypassing” product protections through humans, emotions, and social engineering. We build support so that it is not a weak link, but, on the contrary, an additional layer of protection. For this, service security for us is not an “operator instruction”, but architecture: rules, constraints, confirmations, audit, risk scenarios, and continuous control.

---

17.1. No Calls policy as the baseline defense against social engineering

Info

We eliminate an entire class of attacks with one rule: we do not call and we do not accept calls. Any call “from DARCA” is fraud.

17.1.1. Why this is critical

A phone call:

• is easy to spoof
• is easy to use for pressure (“urgent”, “you are being hacked”, “tell me the code”)
• is hard to prove in an investigation
• has no built-in status/case and audit trail like a digital perimeter

Therefore, we fix the rule:

• we do not call and do not accept calls
• any call “from DARCA” = fraud

This is the foundation that removes a huge class of attacks.

17.1.2. How do we embed this in the product

• warning in settings and security
• block in onboarding
• chat scenario “they called me from DARCA” - protective actions
• Academy lesson on fraud

---

17.2. Separation of powers: the operator cannot perform a critical action

Note

Support can explain and prepare an action, but cannot “perform a critical action” instead of the user. This reduces the risk of errors and pressure on the operator.

We deliberately design support so that even a good operator cannot “accidentally” make a mistake, and a fraudster cannot “talk” an operator into doing something dangerous.

17.2.1. Critical actions: always confirmed by the user

Any action that is related to:

• transfers
• confirmations
• signatures
• security changes
• high-risk operations

is performed only through a button and user confirmation inside the application.

The operator and AI:

• prepare the action
• explain it
• provide the button

but execution always goes through user confirmation.

17.2.2. Step-up confirmation for increased risk

If the risk is high (new device, atypical behavior, suspected fraud), we strengthen confirmation:

• additional confirmation steps
• time limits on the validity of the button
• repeated context verification

The point is: even if someone gains access to the conversation, they will not be able to “perform the action”.

---

17.3. Support as part of the risk perimeter: protective scenarios in one click

Tip

Security is not a memo, but scenarios. In a critical moment, the most important thing is fast steps that reduce risk immediately.

We make security not a “memo”, but buttons.

17.3.1. Core protective scenarios in the chat

The chat always has quick buttons:

• “Suspected account compromise”
• “They called me from DARCA”
• “I do not recognize this transaction”
• “Suspicious activity”
• “Access problem”

17.3.2. What a protective scenario does

Depending on the situation, the system:

• records the event in the case
• shows recent logins and devices
• предлагает завершить все сессии (кроме текущей) - по подтверждению пользователя
• offers to strengthen confirmations
• offers to temporarily restrict risky operations - with user confirmation
• creates a Sev-1 case and connects an on-call specialist if necessary

Principle: a protective scenario must reduce risk immediately, not “wait for an operator”.

---

17.4. Protection against support impersonation in messengers

Warning

External messengers are a convenient channel, but they also create the risk of impersonating an “official account”. We close this risk through verification and binding inside the application.

Since we use external messengers, we must exclude the situation where “a user writes to a fake account”.

17.4.1. Official channels are confirmed inside the application

The application has a section:

• “Official DARCA channels”
• exact accounts, IDs, names
• verification instructions

17.4.2. Binding a messenger to the account

For a user to receive full support in a messenger:

• they confirm the connection through the application
• after that we are sure that the channel belongs to this user

17.4.3. Any critical steps are still redirected to the application

Even if the user is communicating in Telegram:

• a critical action is not performed there
• we provide a “Continue in the application” button

---

17.5. Anti-fraud triggers in support

Info

Support is an early risk sensor: signals of an attack are often visible in text and behavior before damage occurs. We turn these signals into automatic reactions.

17.5.1. Risk signals in text and behavior

Examples:

• “they called me”, “they told me to say the code”, “security service”
• “urgent”, “help cancel”
• “I lost my phone”
• atypical requests to change settings
• sharp changes in behavior and activity

17.5.2. System reactions

• moving the case to priority mode
• activating protective scenarios
• requesting additional confirmations
• restricting “dangerous” buttons until step-up is completed
• connecting an operator/specialist

---

17.6. Audit and provability: who did what, why, and on what basis

Note

We make support investigable. This protects the user, the company, and the operators - because any actions have a transparent trail.

Support must be investigable. Therefore, we record:

• all messages
• all actions
• all statuses
• all issued buttons
• all user confirmations
• all operator decisions

This protects:

• the user (it is possible to prove what happened)
• DARCA (it is possible to prove the correctness of actions)
• operators (cases can be reviewed fairly, without “by eye”)

---

17.7. Quality control and AI security

Danger

AI must not become a source of risk. We restrict it with rules and controls just as strictly as any other part of a fintech system.

AI in support is a powerful tool, but we do not allow it to:

• propose dangerous actions
• violate confirmation policies
• divert the user to external channels for critical actions

We define the rules:

• AI never asks for codes, seeds, or passwords
• AI never “accepts” critical confirmations in the chat
• AI always sends critical actions for confirmation in the application
• Supervisor AI and internal checks track violations and block risky patterns

---

17.8. Summary: support strengthens security, not weakens it

Example

As a result, support works like a shield: it helps the user but does not create bypasses for attacks.

Through:

• отказа от звонков
• confirmation of critical actions only by the user
• protective scenarios in one click
• messenger binding
• risk triggers
• audit and quality control

we turn support from an “attack point” into a real element of protection for the user and the platform.

18. The Future: Messenger Module and financial features directly in chat

The DARCA chat evolves from support into a full-fledged Messenger Module, where financial agreements become objects with statuses, without losing control and security.

Info

We design the DARCA chat so that it is not a temporary “support window”, but the foundation of a communication and financial layer that can scale over time into a full messenger.

Why we are moving toward a messenger

Users already have a habit: important actions and agreements happen in chats. But financial actions are often “detached” from communication, which creates systemic pain points:

• agreements exist, but the transfer has to be made “somewhere else”
• documents are discussed in a messenger, but must be signed “somewhere else”
• debts and settlements are tracked manually
• confirmations and statuses get lost

That is exactly why we develop the chat so that financial scenarios are next to communication, and agreements turn into clear objects with statuses and a transparent history.

Note

The logic is simple: when context and action are close to each other, the number of errors, disputes, and “lost promises” is reduced.

The security principle remains the same

Even when the chat becomes a messenger with financial features, we do not change the basic security policy:

• any money operations
• signatures
• critical confirmations

always go through user confirmation in the product (inside the application) with the required level of step-up verification.

Warning

An “action card” may appear in the conversation, but critical actions are never executed “by words in chat” - only through user confirmation inside the application.

What exactly will appear in the Messenger Module

Transfers in chat (P2P and within DARCA)

The user will be able to:

• send money directly in a dialog (contact, number, username)
• attach a comment
• see the transfer status as a card in the conversation

This removes the classic pain point “I sent it, but where is the confirmation and what is the status”.

“Lend money” and settlements in chat

In the chat it will be possible to:

• create a “debt” card
• set a due date and amount
• see statuses “created / confirmed / partially repaid / closed”
• receive reminders

Important: confirmations are always through the user.

Documents and signatures directly in the conversation

The chat becomes the place where:

• a document is discussed
• versions are attached
• signatures are applied (through user confirmation)
• statuses are received “signed / rejected / requires correction”

This is especially important for business and deals.

Payments and invoices in chat

“Invoice cards” appear in chats with actions:

• “pay”
• “confirm”
• “split into parts”
• “remind later”
• “generate receipt/document”

This turns the chat into a convenient interface for financial scenarios without losing control: the user sees terms and statuses, and confirms critical actions inside the application.

Why we can do this without rewriting the product

We are already building the foundation correctly:

• Support Core (cases, statuses, audit, documents)
• action buttons (deep-links, actions, confirms)
• workflow (processes with statuses)
• AI Layer (assistant, copilot, supervisor)

The Messenger Module is:

• a new interface and a new type of “dialog” (peer-to-peer, groups)
• but on the same base layer: actions, confirmations, document flow, audit

Summary: we expand the platform with a module, rather than creating “a new system from scratch”.

Tip

This approach is important for scale: new scenarios appear as an extension, not as a “second product” that must be supported and secured again.

How this impacts the service

When the chat turns into a messenger:

• users communicate more often inside DARCA
• the habit of using the assistant grows
• issues are resolved faster because the context is always nearby
• financial actions become transparent (cards, statuses)
• there are fewer “lost agreements” and disputed situations

This makes customer service not “reactive”, but part of the user’s daily communication and financial life.

Smooth evolution without abrupt changes

We are not making an “interface revolution”. We are doing a gradual expansion:

1. support chat with buttons and documents (now)
2. expansion of actions (more scenarios, more documents, more automations)
3. adding financial cards in chat (initiation)
4. a full-fledged Messenger Module as a module for those who need it

Principle: nothing unnecessary is imposed on the user. They enable the module only if they need it.