Team

Founders

The founding pair covers DARCA’s key linkage: product framing and commercial execution on the CEO side, architecture, integrations, and bank-grade delivery on the CTO side.

Info

For DARCA, the critical factor is not “feature velocity”, but the ability to sustain trust through quality, managed change, and a predictable transaction outcome at scale.

CEO - Max Shaitor

Max Shaitor is an entrepreneur and product leader responsible for DARCA’s strategy, product, business model, partnerships, and commercial execution. His profile combines corporate product training, work with the enterprise layer, and hands-on experience building proprietary technology products in the Venture building model - from concept and MVP to scaling.

Max’s corporate background includes product management roles at X5 Retail Group, MTS, and Alfa-Bank. This track shaped skills that are especially important for a bank-grade product: discipline in hypothesis and funnel work, product metrics, backlog prioritization and roadmap management, as well as the habit of making decisions in an environment with elevated demands for quality and control.

A separate layer of experience is commercial execution and delivery of complex projects for highly regulated industries. Together with the CTO, Max founded and grew a digital agency working with the financial sector and international brands. This stage matters not because of “logos on a list”, but because of execution risk management practice: many stakeholders, legal correctness, reputational constraints, deadlines, quality, and managed expectations - exactly the discipline later transferred into partnerships, compliance, and banking service rollout.

The focus then shifted to building proprietary products - Sherlock, AME, FRAME, and XBank. In this line, Max acted as the owner of the product frame: value proposition, positioning, UX architecture, monetization logic, and Unit economics, as well as organizational setup for iteration and growth.

XBank became the practical base where the team validated key expectations for a financial interface and transactional product behavior: how the user understands an operation outcome, how they see statuses, where transparency “before confirmation” is required, and what level of reliability is perceived as “normal”. For the CEO, this matters because DARCA does not start from an abstract idea - the product frame has proven solutions that are then scaled into the Core+Modules platform.

Tip

The CEO’s strength is the ability to maintain core focus while simultaneously building the commercial layer: partnerships, packaging, monetization, and trust, without breaking the product in pursuit of short-term metrics.

CTO - Maxim Menkov

Maxim Menkov is DARCA’s CTO, responsible for architecture, integrations, reliability, and delivery of a bank-grade product. His profile combines enterprise discipline (processes, quality, stability) with startup-speed product delivery - from architecture and integrations to a sustainable release cycle.

Before DARCA, Maxim worked as a project manager in IT companies and later at Alfa-Bank, where he contributed to infrastructure initiatives, including the implementation of the SBP. This experience matters because it forms an engineering model of “bank-level” delivery: working with highload services, demanding fault tolerance, understanding SLA, and controlling change in an environment with many stakeholders.

As a technical leader, Maxim builds the delivery layer so that the product evolves predictably: coordinating cross-functional teams, managing the release cycle, controlling quality, post-release monitoring, and eliminating root causes of incidents. For DARCA, this is directly tied to the promise of “one daily bank” - the product must be not only functional, but manageable as load grows and modules expand.

Technologically, the CTO’s key responsibility zone is architecture, integrations, and resilience: internal and external API, observability, monitoring and alerting, incident control, as well as component scalability over time. In the entrepreneurial layer, Maxim together with the CEO developed an agency, owning technology execution and delivery quality. He later participated in building Sherlock, AME, FRAME, and XBank, shaping engineering standards and managed release practices.

XBank became the technological base where the team solidified the principles of moving from MVP to an industrial-grade bank: speed and stability, architectural decisions, integrations, and release discipline. For the CTO, this confirms that DARCA’s engineering is built not “in theory”, but on a practical habit of keeping the product in operational mode.

Warning

In banking products, development speed is valuable only when it does not destroy correctness, observability, and change control. This is exactly the CTO’s responsibility zone as the owner of bank-grade delivery.

CEO + CTO linkage

The founder linkage in DARCA is designed as a division of responsibility that reduces the key early-stage risks. The CEO maintains the product frame, monetization, and partnerships, while the CTO ensures architectural integrity, integrations, and predictable system evolution. As a result, DARCA is built as a managed platform, where trust is delivered not through statements, but through engineering discipline, operational maturity, and a user-clear outcome of every transaction.

Team

The DARCA team is built around bank-grade layers - 24/7 operations, security SDLC, transactional correctness, money UX, service, and legal resilience.

Info

In DARCA, the team is described as a system of closed loops that sustain trust in practice - through correctness, observability, and managed change.

The DARCA team is structured around a set of functions that cannot be “added later” in a financial product. These are the layers that ensure predictable transaction outcomes, clear statuses, infrastructure reliability, development security, and legal correctness of rules and documents. This composition is required specifically for a daily bank, because users evaluate a bank not by the number of screens, but by how stable, transparent, and honest the product is in critical scenarios - transfers, exchanges, asset custody, confirmations, and disputed situations.

Layer	Owner	What it covers
Platform, DevOps/SRE	Artem Lebedev	24/7 operations, observability, HA/DR, on-call, zero-downtime releases
DevSecOps/Platform	Ilya Gromov	secure SDLC, secrets and keys, audit readiness, supply chain security
Backend/Core	Sergey Volkov	ledger, transaction statuses, idempotency, integrations, crypto rails, highload 24/7
Design	Anton Bondar	money UX, design system, error-prevention patterns, Core+Modules consistency
Frontend	Nikita Orlov	bank-grade UI, statuses and async flows, performance, frontend observability, API contract discipline
Support/Ops	Anastasia Dyachkova	L1-L3, SLA, CSAT/FCR, incident support, knowledge base, escalations
Legal	Viktor Bolotov	contracting layer, user documents, data and privacy, IP, claims

Note

The key difference is that these layers work together. Stability and security do not compete with speed - they define the boundaries within which the product can grow without losing trust.

Artem Lebedev - Head of DevOps/SRE

Artem is responsible for ensuring DARCA is predictable as a system: the product stays available, degradations are detected before they become user problems, incidents are resolved quickly, and releases do not turn into risk. His responsibility zone is operations as part of the product, where reliability is measured not by promises, but by the discipline of monitoring, response, and prevention.

In his experience, Artem focuses on SRE and production operations practices, where value is defined by how well an engineering organization can sustain high availability, ensure recovery, and preserve managed change. For a financial product, this is critical, because any unpredictability in statuses or downtime instantly разрушает trust and increases operational risk.

Key outcomes he delivers in DARCA:

• observability as a standard: metrics, logs, traces, dashboards, and alerts, so the system is measurable
• incident management: triage, on-call, postmortems, and preventive actions
• fault tolerance: recovery plans, redundancy, failover scenarios, RTO/RPO control as practice
• release discipline: zero-downtime approaches, canary and rollback as normal tools
• infrastructure cost management without reducing reliability

Tip

SRE in DARCA is not “server support”, but protection of product predictability: if the system is observable and changes are managed, the user sees honest statuses and receives a trusted outcome.

Ilya Gromov - Lead DevSecOps/Platform

Ilya is responsible for security as an engineering system embedded into the development lifecycle. His role is to ensure that security is not a separate stage “after development”, but part of the process: from source code and CI/CD to secrets, key management, and infrastructure.

Ilya’s experience is in DevSecOps and platform security, where the core value is building security-by-design practices that scale together with the product. For DARCA, this means that access control, keys, dependencies, and infrastructure changes become predictable and provable, rather than dependent on manual agreements.

What he delivers in DARCA as a system:

• secure SDLC: standards, checks, and gates that reduce the likelihood of vulnerabilities in release
• management of secrets and keys: storage, access, rotations, least privilege
• CI/CD and container platform security, supply chain control
• audit readiness: preparation of processes and artifacts that allow audits to be passed without chaos
• infrastructure risk control as part of engineering discipline

Warning

For a financial product, a security incident is not a “bug”, but a risk to trust and money. That is why security in DARCA is a process, not a one-time audit.

Platform/SRE + DevSecOps linkage

Platform and security in DARCA operate as a single risk management loop. Reliability is impossible without secure change, and security brings no value if the system crashes or degrades. In this linkage, access standards and infrastructure changes, release practices, incident response, and postmortems set general discipline where changes are observable, reversible, and verifiable.

Sergey Volkov - Lead Backend Go

Sergey is responsible for DARCA’s transactional core and for ensuring that the money system is correct, transaction statuses are predictable, and integrations remain reliable under load. His focus is bank-grade backend, where the primary success criterion is not development speed, but correctness, idempotency, and observability of critical operations.

Sergey’s experience is tied to building highload transactional services and practices that keep a product operational 24/7: a correct accounting model, resilient integrations, reliable handling of errors and retries, and clear status logic that matches what the user sees.

What he delivers in DARCA:

• transactional core and accounting: a ledger approach and balance consistency
• transaction statuses as a state machine, to eliminate “grey zones” and disputed states
• idempotency, outbox-inbox patterns, protection against duplicates and races
• event-driven interactions and integrations, including crypto rails and transaction confirmations
• an “operation dossier” as an engineering and operational artifact for support and RCA
• observability of critical paths and readiness to operate in highload 24/7 mode

Example

In bank-grade logic, what matters is not only the fact that “the transaction succeeded”, but that every status is explainable, reproducible, and provable through the event chain. This reduces disputes, lowers support load, and sustains trust.

Backend/Core + SRE linkage

The transactional core and operations function as one discipline: system health is measured not only by CPU and memory, but also by transaction metrics, statuses, queues, integration errors, and the time it takes to complete critical scenarios. This linkage enables fast RCA, predictable recovery, and degradation control without breaking the user experience.

Anton Bondar - Chief Design Officer

Anton is responsible for DARCA’s UX/UI strategy and for ensuring that the interface works as a rule system, not as a collection of separate screens. In a banking product, design defines not “beauty”, but the manageability of user behavior: how many mistakes they make, how quickly they understand the transaction outcome, and how much they trust the interface in stress scenarios.

Anton’s experience lies in systemic design and building a design system, where the goal is to maintain consistency as the product grows, especially when new modules and complex financial scenarios appear. For DARCA, this means a unified language of statuses, confirmations, warnings, and previews that protects the user from errors and reduces operational risk.

What he delivers in DARCA:

• design system and interface rules that preserve Core+Modules integrity
• money scenarios as a set of resilient patterns where the user understands “what will happen” before confirmation
• error-prevention mechanics: warnings, previews, confirmations, clear states
• consistency of transaction statuses and terminology across the entire product
• design as a tool to reduce support load and minimize disputed cases

Nikita Orlov - Lead Frontend

Nikita is responsible for DARCA’s client-side interface implementation and for frontend quality as an engineering system. His zone is ensuring that money flows and statuses work without ambiguity, that the product is fast and stable, and that client-side degradations are detected and fixed systematically.

Nikita’s experience is tied to building complex interfaces where async behavior, correct status handling, integrations, and API contract discipline are critical. In a bank, the frontend is the “face of trust”: if the interface is unstable or shows unpredictable states, the user perceives it as a banking problem, even if the backend is functioning.

What he delivers in DARCA:

• implementation of “money” scenarios and transaction statuses as clear and stable logic
• performance and reliability of the client application
• frontend observability: control of errors, crashes, degradations, and their linkage to server metrics
• API contract discipline and regression minimization
• translating the design system into code, so design remains a system, not a set of unique screens

Tip

The Design + Frontend linkage establishes a unified interface language. The user sees not “different modules”, but one system where statuses, confirmations, and rules are consistently clear, which strengthens trust.

Anastasia Dyachkova - Head of Support

Anastasia is responsible for DARCA’s support and operational layer, which functions as an extension of the product. Her task is to build L1-L3 processes where response speed matters, but even more important are correctness, reproducibility of resolutions, and the right linkage with engineers and the transaction status layer.

Anastasia’s experience includes support management, an SLA-driven approach, quality control, and incident work. In DARCA, support becomes part of the product: for the user, it is not only important to get an answer, but also to receive a clear status explanation, the correct action scenario, and a resolution that reduces the likelihood of recurrence.

What she delivers in DARCA:

• L1-L2-L3 management, routing, prioritization, and SLA
• service quality: communication standards, knowledge base, answer quality control
• incident support as part of overall incident management together with SRE and backend
• escalations with context and feedback into the product to eliminate root causes of recurring issues
• operational procedures that reduce manual errors and increase outcome predictability

Viktor Bolotov - Chief Legal Officer

Viktor is responsible for DARCA’s legal layer and for ensuring that the product is resilient not only technically, but also legally: documents, data, contractual foundation, IP, and claims procedures. In fintech, legal correctness is part of trust, because it defines liability boundaries, data handling order, and the rules of interaction with users and partners.

Viktor’s experience is tied to contract work, preparation of user-facing documents, privacy matters, and legal risk management. In DARCA, his role ensures that legal requirements do not chase the product after release, but are embedded into processes and scenarios.

What he delivers in DARCA:

• the contractual layer and user documents aligned with product logic
• the data layer: DPA, processing rules, privacy, and correct liability wording
• IP protection and legal discipline in partnership relationships
• claims procedures and readiness to respond to disputed situations correctly and predictably

Question

In a bank, what matters is not only the product, but how provably correct it is: what can be explained to the user, confirmed with logs and documents, and resolved in support without “manual guessing”.

Taken together, the DARCA team covers the full critical loop of a bank-grade system: reliability and operations, development security, money and status correctness, interface quality, operational service, and the legal foundation. These roles are connected through shared processes and artifacts - observability, incident management, the transaction status model, the design system, the knowledge base, and legal templates - which is why DARCA evolves as a managed platform, not as a set of fragmented functions.

Our Experience

The DARCA team’s experience is a combination of enterprise fintech, bank-grade engineering, crypto services, and scalable product launches, validated by projects, metrics, and real-world operations.

Info

We demonstrate experience through facts and results: what exactly the team built, at what scale it operated, which processes and standards were required, and why this transfers into DARCA.

DARCA is built by a team with hands-on experience in creating and operating digital systems with high requirements for reliability, security, and predictability of outcomes. This experience spans several classes of tasks critical for a bank: enterprise-level processes and integrations, a real 24/7 support layer, product discipline and measurability, as well as the crypto domain - from payment scenarios to building proprietary token economics within an ecosystem.

Founders: experience, competencies, stack

CEO - Max Shaitor

Max Shaitor is an entrepreneur, product leader, and founder of DARCA. His core competence is turning an idea into a managed product, assembling a business model, structuring priorities, partnerships, and growth, and maintaining execution discipline over the long term.

Max’s corporate background includes product management roles at X5 Retail Group, MTS, and Alfa-Bank, where he developed digital services and product initiatives at the intersection of business, technology, and customer experience. In such an environment, the key skill for a bank is formed: treating the product not as a set of features, but as a system where every change passes through metrics, funnels, and a managed roadmap.

The entrepreneurial stage included founding and scaling a digital/advertising agency together with the CTO. The agency worked with major companies and highly regulated industries where compliance, reputational risk, and strict execution standards are critical. Financial sector projects included Alfa-Bank, Sberbank, VTB, Tinkoff, Raiffeisenbank, Otkritie. International brands included IKEA, British American Tobacco, Diageo, Renault. This experience directly transfers to DARCA as a bank, because it includes complex approvals, legally correct communications, management of large stakeholder expectations, and the ability to deliver projects to completion.

Max’s focus then shifted to venture building and creating proprietary products: Sherlock, AME, FRAME, XBank. In each of them, product packaging, value proposition, user journeys, monetization logic, analytics, and iterative improvement cycles were refined.

Max’s competency stack as CEO of a bank-level product:

• product strategy and prioritization: value, risk, cost, time-to-value
• analytics and metrics: cohort analysis, funnels, retention, LTV, unit economics
• commercial and partnerships: negotiations, terms, SLA-driven approach, execution quality control
• product launch and growth: discovery-delivery cycle, change management, market expectation management

Tip

In a bank, the CEO is responsible not for the “idea”, but for the integrity of the product: user trust arises when the system is predictable and development does not break core scenarios. This skill is formed only through real launches and complex commercial environments.

CTO - Maxim Menkov

Maxim Menkov is DARCA’s CTO with experience implementing complex IT initiatives in corporate and fintech environments. His profile combines enterprise development discipline (quality, reliability, change control) with fast delivery practice without losing manageability.

Before DARCA, Maxim worked as a project manager in IT companies and later at Alfa-Bank as an internal project manager, participating in infrastructure initiatives, including the implementation of the SBP. SBP is the “Faster Payments System”, an infrastructure layer where stability, integrations, SLA, security, and change control are critical. Experience of this class of projects is important for DARCA because it forms a bank-grade engineering approach: predictable releases, observability, integration discipline and accountability for fault tolerance.

In DARCA and previous projects, Maxim covers the architecture + integrations + resilience linkage: digital service design, development of internal and external APIs, monitoring and incident response approaches, and scalability as load grows. He also built the agency’s technology layer, owning implementation, delivery, team management, and execution quality for large clients.

Maxim’s competency stack as CTO of a bank:

• service and integration architecture: API-first, contract discipline, versioning
• delivery and release cycle: planning, quality, monitoring, post-release control
• observability and incident management: monitoring, alerting, diagnostics, MTTR reduction
• technical quality management: development and testing processes, technical debt control, standards

Note

Experience in implementing infrastructure payment layers and working in a banking environment reduces the main early-stage risk - the risk of “not holding the system” when the product begins to grow in load and number of integrations.

Experience, stack, achievements

Head of DevOps / SRE - Artem Lebedev

Artem Lebedev is responsible for DARCA’s infrastructure, reliability, and 24/7 operations. He has worked with the team for many years and participated in all key projects (Sherlock, AME, FRAME, XBank), building the engineering foundation that allows the product to grow without losing stability. He has experience in a banking environment where availability requirements, change control, observability, incident management, and disaster recovery are critical.

Artem’s fintech task profile:

• operation of critical services 24/7 with focus on resilience and predictability
• SRE practices: SLI/SLO, error budget, on-call, postmortem, MTTR reduction
• HA and DR fault tolerance: redundancy, replication, regular recovery testing
• zero-downtime delivery: blue/green and canary, safe updates without downtime
• observability as a standard: metrics, logs, traces, SLO-driven alerting

Artem’s technology stack:

• Docker, Kubernetes, Helm
• Terraform, Ansible, GitOps practices
• GitLab CI / Jenkins, rollout/rollback strategies
• Prometheus, Grafana, Alertmanager, Loki/ELK, OpenTelemetry/Jaeger
• PostgreSQL (HA/replication), Redis, Kafka/RabbitMQ
• private networking, VPN, bastion, environment segmentation, hardening, least privilege

Result for DARCA: Artem is responsible for what turns the product into a bank, not an “app”: measurable reliability, managed releases, and the ability to withstand load growth without chaos.

Lead DevSecOps / Platform Engineer - Ilya Gromov

Ilya Gromov is responsible for infrastructure security and the software supply chain (secure SDLC), secrets and key management, access control, and audit readiness. He participated in all team projects (Sherlock, AME, FRAME, XBank) and ensures security discipline without sacrificing development speed. He has experience in banking environments where auditability, change traceability, and regulated access are critical.

Ilya’s task profile:

• DevSecOps as part of the pipeline: security is “built-in”, not checked at the end
• audit readiness: logging, change traceability, privilege control
• secrets and keys: centralized storage, rotations, access policies, audit trail
• container and supply chain security: scanning, runtime policies, artifact protection
• network security: segmentation, mTLS/encryption, ingress restrictions, WAF approaches

Ilya’s technology stack:

• HashiCorp Vault (or equivalents), KMS approaches, rotations, and access segregation
• SAST/DAST/dependency scanning approaches, quality gates in CI/CD
• image scanning (Trivy or equivalents), artifact signing and verification (cosign approaches)
• OPA/Gatekeeper/Kyverno approaches, “security as code”
• Kubernetes, Helm, Terraform, GitOps
• centralized logs, audit, and event correlation (security observability)

Result for DARCA: Ilya reduces the risk of security incidents and makes security part of the pipeline, not an “external control” after the fact.

Lead Backend Engineer (Go) - Sergey Volkov

Sergey Volkov is responsible for server architecture, transactional correctness, and the platform’s operational maturity. His profile includes bank-grade backend (resilient 24/7 services, predictable releases, data discipline) and a strong crypto domain: building crypto payments, wallet layers, and services around decentralized protocols.

Financial core and correctness:

• money scenario services: accounts, balances, transfers, transaction history, statuses, notifications
• accounting layer (ledger) with double-entry principles and integrity control
• reconciliation: state alignment between internal systems and external sources
• resilience to partial failures: “stuck” statuses, duplicate events, external timeouts

Integration reliability:

• idempotency, retries, deduplication, outbox/inbox approaches
• queues and eventing, degradation handling, monitoring of external dependencies
• API contract discipline, versioning, technical debt management

Crypto layer:

• payment gateway and on-chain confirmations as an operational layer
• resilience to network instability, event handling, protection from missed and duplicate events
• wallet infrastructure (hot/warm/cold layers), withdrawal policies, audit
• integrations via RPC/Web3 providers, failover, event indexing

Sergey’s technology stack:

• Go (golang)
• REST/gRPC, OpenAPI/Swagger, contract-driven approach
• PostgreSQL (transactional core/ledger), Redis
• Kafka / RabbitMQ / NATS, eventing, outbox/inbox
• Prometheus, Grafana, OpenTelemetry, ELK/Loki
• Docker/Kubernetes, 12-factor, configuration via env/secret management

Result for DARCA: Sergey safeguards a key part of trust - correctness of accounting and statuses, and resilience of the money and crypto layer in real operations.

Lead Frontend Engineer - Nikita Orlov

Nikita Orlov is responsible for client architecture, quality, and interface performance. He participated in the development of all key products (Sherlock, AME, FRAME, XBank) and builds a “bank-level” frontend approach: correct money flows, resilience to user errors, client-layer security, and measurable release quality.

Nikita’s task profile:

• money scenarios: accounts, balances, transactions, transfers, confirmations, transaction statuses
• error reduction: validations, warnings, confirmations, safe states
• async and consistency: correct pending/success/failed states
• backend contract discipline: data schemas, versioned changes, UX stability
• e2e control of critical flows and performance control as a trust factor

Nikita’s technology stack:

• TypeScript / JavaScript (ESNext)
• React / Next.js
• Redux Toolkit / Zustand, React Query, WebSocket/SSE
• design system, Storybook
• React Hook Form, Zod/Yup
• Jest, Testing Library, Cypress/Playwright
• Vite/Webpack, ESLint, Prettier
• Sentry or equivalents, performance metrics

Result for DARCA: Nikita ensures that the “money UX” remains predictable as functionality grows, and the product does not break trust due to client errors or status inconsistencies.

Head of Technical Support - Anastasia Dyachkova

Anastasia Dyachkova is responsible for customer service quality and operational resilience of support, where any delay directly impacts user trust. Her profile includes managing support and service operations in digital products, building regulations and metrics.

Anastasia’s task profile:

• L1/L2/L3 model with routing and escalation rules
• SLA-driven approach: first response time, time-to-resolution, queue discipline
• quality metrics: CSAT, ticket reasons, self-service share, recurrence control
• support for money scenarios: transaction statuses, disputed cases, access recovery
• incident support: primary diagnostics, data collection, communication during incidents, participation in postmortem

Tools and process base:

• helpdesk and omnichannel systems (Zendesk/Freshdesk/Intercom class)
• Jira, Knowledge Base, escalation regulations, templates, and instructions
• communication QA, operator training and certification
• self-service: knowledge base and automation of typical requests

Result for DARCA: support becomes part of the product and strengthens trust, rather than turning into a growth bottleneck.

Chief Legal Officer - Viktor Bolotov

Viktor Bolotov is responsible for the product’s legal architecture, the contractual layer, protection of company interests, and risk management during scaling. He has experience supporting IT projects and digital services: contracts, liability, IP protection, claims processes and legal product structuring.

Viktor’s task profile:

• contracts with partners and vendors: liability, SLA, penalty models, DPA/data processing
• user documents: offer, terms of use, privacy policy, consents
• legal support of product rules and communications
• data and privacy: storage/processing requirements, access control, incident response
• IP and rights: trademarks, rights to software/design/content, contractor agreements
• claims and litigation work: regulations and standardization

Result for DARCA: the legal foundation reduces the risk of post-launch “rework” and ensures resilience of partnerships and service rules.

Chief Design Officer - Anton Bondar

Anton Bondar is responsible for UX/UI strategy, the design system, and customer experience quality. He led the design team at Tinkoff Bank. During his tenure, the product confirmed its leadership in mobile banking through industry recognition: in 2021, Tinkoff received the Frank Cards & Reward Award 2021 for Best Mobile Daily Banking App.

Anton’s task profile:

• UX of critical money flows: confirmations, statuses, errors, disputed cases
• design system: components, guidelines, consistency, and interface scalability
• process: research, prototyping, usability testing, collaboration with product analytics
• implementation quality: collaboration with frontend, UI control in production, visual quality standards

Result for DARCA: design transforms complex financial operations into simple and safe scenarios and reduces the class of errors that most often break trust in daily banking.

Example

It is important that these roles have already worked together across several products - this is not a “set of strong individuals”, but a coordinated loop of processes and standards: platform + security, backend + SRE, design + frontend, support + engineering, legal + product.

Projects and results: what exactly was built and which metrics prove the level

Sherlock - customer service, chatbot, and messenger platform

Sherlock was a built and sold project, a unified platform for automating customer service, sales and marketing via messengers (Telegram, WhatsApp, iMessage, website chat). The platform enabled centralized communication management, analytics, Artificial intelligence, and automation.

Key Sherlock metrics:

• 600+ corporate clients, including market leaders (for example: “Zolotoye Yabloko”, Motul, 12 Storeez, ORTEKA, Sportmaster, Rosbank, British American Tobacco)
• each large client processed over 600,000 dialogs per month
• total monthly platform volume exceeded 7-10 million dialogs
• total company revenue exceeded 100 million rubles
• average annual revenue growth of approximately 30-40%
• reduction of operator workload for clients by 50-60% through AI and chatbots
• average reduction of client operational expenses by 25-30%
• CSI growth to 87%
• client sales growth through automation and analytics of approximately 15-20%

Transferability to DARCA: this experience forms the foundation for support and communication layers, where chat is part of the product and processes are measurable and manageable.

AME - augmented reality platform and technological foundation for FRAME

AME was a delivered project (2019) that included two mobile applications (for businesses and end users). The platform enabled businesses to create and manage AR content that users interact with through a smartphone camera without special markers.

Key AME metrics:

• AR content loading and binding time of less than 2 seconds
• Skolkovo Foundation grant - 84 million rubles
• average campaign engagement growth up to 25-30%
• average brand recall after AR interaction above 80%

Transferability to DARCA: AME strengthens the team’s competence in mass-market products, high-speed UX, and technological discipline, and became the foundation for the next stage - FRAME, where a crypto layer was added.

FRAME - decentralized ecosystem for AR marketing and mobile mining, plus creation of a proprietary cryptocurrency

FRAME was a project (2021) that combined a marketing agency and a mobile application around its own cryptocurrency, complementing the AR platform with distributed computing architecture and user incentives through mobile mining (ARM processors). FRAME is important as proof that the team can build not only a product layer, but also crypto infrastructure with measurable characteristics.

FRAME metrics for the agency and AR layer:

• successful AR solution implementations for major brands, including “Gazprom”, Coca-Cola, British American Tobacco, IKEA, Adidas, H&M
• more than 50 large marketing campaigns per year, reaching millions of users
• average conversion growth of 20-25% for clients using AR solutions

FRAME metrics for the crypto layer and mobile mining:

• more than 35,000 users in the first year
• average transaction speed of less than 0.7 seconds
• network throughput reached 1,482 TPS
• distributed mobile mining model (ARM), enabling up to 40% savings on server costs
• FRAME cryptocurrency was used as a settlement instrument within the ecosystem, supporting internal economics and incentives

Transferability to DARCA: FRAME provides experience in building crypto services, decentralized layers, and token incentives, including engineering requirements for speed, resilience and ecosystem economics.

XBank (MVP DARCA) - proven operations, real metrics, and evidence of manageability

XBank is DARCA’s MVP and a practical stress test of “fiat + crypto in one app”. The pilot ran in Russia from October 2024 to May 2025 and was designed to test habit formation, trust and resilience of critical actions on real transaction volume.

MVP composition as an integrated layer:

• fiat balances: RUB, USD
• crypto assets: USDT (TRC-20), TRX, USDT (BEP-20), BNB
• key user layers: internal transfers, in-app exchange, P2P as entry-exit, early RWA test (real estate share), in-app support, and a basic risk layer

Actual XBank pilot metrics (MVP DARCA):

• registrations: 42,653
• completed KYC: 26,879 (KYC)
• made 1+ transaction: 26,044
• total transactions during pilot: 570,515
• uptime: 99.95%
• TTV (total transaction volume): $62.1M
• DAU/MAU: 19-22%, peak up to 32%

Metrics of key behavioral layers:

• internal transfers: 34% of all operations, confirmation and status in less than 1 second
• in-app exchange: volume around $8.1M, with “You pay / You receive” preview
• P2P: volume around $9.1M, 34,839 deals, median close time around 17 minutes, dispute rate around 1.8% (Escrow)
• operational maturity: in working phase W15-W29 transactions held at 17-39k per week

Support as part of the product (actual MVP metrics):

• 24/7 support
• median first response: 7.4 min
• FCR: 72%
• CSAT: 4.2/5

Warning

For an investor, what matters is not the “presence of features”, but proof that the system withstands scale without breaking statuses and without degrading trust. 570,515 transactions represent a distance at which any weak points become visible, which is why this metric is one of the key proofs of readiness for the next market.

DARCA’s strength is not an individual talent, but a combination of experiences that covers the full bank-grade product cycle: product discipline and commercial execution (founder), enterprise engineering and payment layers (CTO), 24/7 operational maturity (SRE), security and audit readiness (DevSecOps), accounting correctness and transaction resilience (backend), money UX and client-layer quality (frontend + design), support as part of system reliability (support), and legal structuring of rules and partnerships (legal). Together, this reduces execution risk, accelerates entry into the next market, and delivers the key capability - the ability to sustain trust in a product where trust is measured by repeatable actions and stable statuses, not promises.

Additional Roles We Need

The team scales modularly around Core+Modules: we close product and operational resilience layers, not “hire everyone at once”. This list is a functional map of needs, without reference to the order of hiring.

Info

DARCA is Core+Modules. Therefore hiring is structured by layers: first, the foundational bank-grade capability is secured (money correctness, security, operations, compliance, support), then roles for specific modules are added. This is not a hiring order, but a map of the competencies that must exist internally to deliver the full declared functionality.

Below are the minimally required roles missing on top of the already described team. For each role, an estimated headcount sufficient for full functionality is indicated. As load grows, some layers scale not because of new features, but due to parallel development and 24/7 operations.

Core (daily bank) - mandatory foundation

• Cross-platform mobile development - 2

  • Mobile engineers (React Native or Flutter): status-driven flows, confirmations, push, deep-links, secure on-device storage, money UX

• QA and release discipline - 2

  • QA Lead: fintech testing strategy and release gates
  • QA automation: e2e for critical money scenarios, regression, status stability

• Data and reporting - 1

  • Data/Reporting engineer: data marts, exports, statements, tax-ready packages, reconciliation logic at the data layer

• Risk and antifraud - 1

  • Risk/Fraud engineer: rules+signals, hold/step-up, device/behavior signals, anti-scam logic, support-ready cases

• Core integrations - 1

  • Integration engineer: KYC/KYB providers, sanctions, notifications, webhooks, reconciliation and integration idempotency

• Compliance and privacy (EU-first) - 2

  • AML/Compliance Officer (EU): policies, processes, audit readiness
  • DPO/Privacy (GDPR): privacy by design, DPA, data procedures

• Finance and reconciliation - 2

  • Financial controller: control of financial layers and registry discipline
  • Accountant: accounting, reconciliations, documents, operational reports

• Support and operations - 7

  • Support Ops: processes, knowledge base, support QA, automation
  • Support agents 24/7: L1/L2 line, escalations, status and document follow-up

• Legal layer for Core (internal) - 2 in addition to Head of Legal

  • Legal Counsel (commercial/fintech): provider contracts, user documents, claims
  • Regulatory Counsel (EU): licensing and regulatory requirements, legal risk change control

Warning

Critical bank layers must be in-house: finance, legal, compliance, risk, key integrations, custody, and cryptography. Contractors are acceptable only as reinforcement for local country specifics and external audits, but not as substitutes for layer owners.

Payments (online-first checkout и дальнейшее расширение)

• Payments engineer - 1
  • PSP/orchestration, statuses, retries, refunds, reconciliations, resilience of payment scenarios
• Payments operations specialist - 1
  • registries, disputes, operational work with providers, control of payment completion
• Legal Counsel for payments - 1 with the active development of rails
  • contracts with PSPs/issuers, terms, liability, control of obligations

Business (KYB, roles, approvals, audit, integrations, API/webhooks)

• Backend engineer for B2B integrations - 1
  • ERP/CRM integrations, webhooks, scopes, IP allowlist, audit and traceability
• B2B operations/product owner - 1 upon entering the corporate layer
  • approvals, invoices as objects, mass payouts, reconciliation, reporting requirements

P2P (on/off-ramp, rating, auto-reserve/auto-settlement, disputes, anti-scam)

• P2P operations/dispute specialist - 1
  • arbitration, dispute procedures, deal quality control, linkage with risk and support

RWA (T-Bills, Metals, RWA sm, RWA Home)

• RWA partnerships/ops manager - 1
  • partners, escrow, milestones, operational object model
• RWA ops/document controller - 1
  • Object Vault, document packages, stage and status control
• RWA Legal Counsel - 1
  • SPV/escrow, disclosure, contracts, legal model of RWA tokens and market restrictions

Cold Storage и custody (keys, policy engine, network monitoring)

• Custody/Wallet Security engineer - 1
  • MPC/HSM layer or integration, withdrawal policies, chain monitoring, failover RPC, audit and traceability

Token Factory (token issuance) и NFT

• Web3/Smart contract engineer - 1
  • token issuance, NFT, contract security, Web3 integrations, compatibility with external Web3
• Addition within legal+compliance
  • issuance rules by country, disclosure, audience and circulation restrictions

Staking (including liquid staking)

• DeFi/Protocol integration engineer - 1
  • protocol integrations, liquidity/lock accounting, monitoring of protocol risks
• Addition within risk+compliance
  • risk policies and product limitations

Enhanced Security and Anti-crisis vault

• No additional full-time roles required with Core roles in place
  • logic owner - Risk/Fraud engineer
  • implementation and control - security and platform layer, mobile and backend layers
• Reinforcement as scenarios become more complex
  • security analyst - 1 with growth in audits and incidents

Messenger (E2EE и финансовые объекты в чате)

• Messaging backend engineer - 1
  • объекты со статусами, антиспам/антифишинг, интеграции с Core
• Cryptography/E2EE engineer - 1
  • протокол, key management, encrypted backups, key transparency

Piggy bank, Habit tracker, My Games, Mining

• Dedicated engineers are not mandatory with a strong Core team in place
  • these modules are delivered by mobile/backend/QA/data and connected as product layers
• Partnerships/BD for module partnerships - 1 when actively scaling “My Games” or handling regional constraints in “Mining”
  • partners, legal framework, operational processes

DARCA Academy (education as part of the product)

• Content lead - 1
  • learning program, first-result scenarios, reduction of support load
• Instructional designer - 1
  • packaging into micro-lessons, tests, course structure and clarity

Growth and marketing (product-led)

• Growth marketer - 1
  • activation/retention, lifecycle, subscriptions and overage, referrals
• Performance marketer - 1
  • paid channels and creative experiments, CAC optimization

Tip

This list covers the full functional scope of DARCA as a platform. Post-launch reinforcement is usually needed not to add new “mandatory” roles, but to remove bottlenecks: additional QA, stronger data layer, expanded support, and duplication of narrow competencies (custody, cryptography, payments) as load and responsibility grow.

This document presents two layers.

The first layer is the team already in place: founders and specialists capable of holding the product as a managed system, not a collection of screens and features. We already have competencies in Core+Modules architecture, transactional logic and status model, secure development, 24/7 operations, money UX, support as part of the product, and legal structuring. This is the foundation that enables complex decision-making, priority setting and high-level execution.

Note

DARCA already has a formed core team that solves the critical early-stage task - to design a bank-grade system, establish engineering and operational discipline, and bring Core to stable production.

The second layer is the map of additional roles required for full module coverage and acceleration. These roles are not a replacement for the current team - they are amplification for scale. Investment in DARCA primarily enables expansion along these layers, removal of bottlenecks, parallelization of development, and faster module rollout while preserving bank-grade quality and compliance.

Tip

The key capability - people who can design, lead, and deliver DARCA as an international crypto-bank - already exists. Further growth is a matter of pace: with investment, execution scales and Core+Modules becomes a fully realized platform faster.**