Frequently Asked Questions

Smartex Money is a white label fintech platform for launching branded digital banking, payment and financial services. The stack bundles 50+ modules covering core banking, payments, cards, compliance and AI-powered automation, so you assemble one system rather than stitching separate vendor products together. What that means in practice: a licensed EMI adds multi-currency accounts and cards under its own brand without spending half a year building an IT team, and a payment company moves from idea to a working product while core, mobile channel and compliance tooling already speak to each other. Because the modules share one data model, you also avoid the classic integration tax of reconciling three systems that each define a client differently. A closer look at the approach is on the white label platform page.

The platform serves banks, payment service providers, microfinance institutions, electronic money issuers, credit unions, mobile operators and fintech startups. What they share is a need to ship their own financial products without building a core banking system from scratch over several years. Concretely by segment: a bank runs Smartex as a digital overlay for new products, a PSP plugs in payment processing and card issuing, an MFI automates its loan book, and a startup raises a neobank on SaaS in a few weeks. Mobile operators use the same stack to bundle accounts and cards with their subscriber base. If you are unsure whether your case fits, the comparison on the platform comparison page is a good starting point.

With SaaS deployment you can launch in 2-4 weeks; custom implementations typically take 2-6 months depending on scope. The short track works because branding, tariffs and limits sit on top of a running core, so most of the project is configuration rather than development. Custom timelines stretch where the client brings non-standard flows - specific SWIFT routing, unusual fee logic or bespoke KYC steps - or where an on-premise deployment has to be sized and hardened first. Licensing status matters as well: an existing EMI or bank license removes the longest lead time, while a fresh license runs on its own regulatory calendar. We recommend fixing the launch scope in the first sprint and rolling out the rest as phase two, which keeps the date honest and the backlog visible.

SaaS is a monthly subscription with shared or dedicated cloud hosting. Life Time License is a one-time fee with on-premise deployment and full source code. The practical difference shows up in who carries operations: under SaaS we run updates, monitoring and infrastructure, while under Life Time your team owns the servers, the release cycle and the code itself. Cost behaves differently too - SaaS turns the spend into a predictable operating expense, Life Time shifts it into a one-off capital purchase with your own running costs afterwards. A licensed EMI testing a new market usually starts on SaaS and moves to on-premise once volumes justify it. A side-by-side breakdown lives on the comparison page.

Yes. Every aspect is customizable - branding, workflows, fee structures, compliance rules, integrations and the mobile app. Deeper changes are possible as well: tariff logic, KYC steps and approval chains are configuration, while genuinely new product mechanics go in as source-level work under a Life Time License. In our deployments the most requested items are a custom mobile app shell, market-specific fee models and local payment method connectors. One warning from experience: keep customizations documented, because they decide how smoothly major version upgrades land later. For what a customization project typically covers, see our services.

Smartex Money includes native Android and iOS apps that are fully customized and branded for each project. Clients get their own store listings, icon and color scheme, and a typical feature set: accounts and cards, transfers, biometric login, push notifications and transaction history. Card credentials are stored as tokens - the same tokenization approach used by Apple Pay and Google Pay - so PAN data never touches the app environment. The apps ship as part of the platform mobile app module rather than as an external build, which is why new core features appear in the mobile channel without a separate integration project.

Yes. The platform meets PCI DSS requirements for cardholder data protection through Cryptex DB, a virtual HSM layer with AES-256 encryption and tokenization. In plain terms: card numbers are replaced with tokens, keys stay inside the Cryptex DB layer, and sensitive fields never sit in the application database in clear form. That shrinks the PCI DSS audit scope for your card programs and keeps issuing and acquiring flows aligned with scheme rules. In our deployments this is what keeps scheme due diligence questionnaires and client assessments from turning into multi-month exercises. For an acquirer or issuer the difference is a routine assessment rather than a painful one.

AML/KYC is built in: AI-powered automation covers dynamic verification flows, OSINT intelligence, sanctions screening, PEP checks and risk scoring. Verification adapts by segment and risk tier, so a low-risk wallet user clears a lighter flow while a business account goes through enhanced due diligence. Screening results and risk scores are written back to the client profile, which gives your compliance team one audit trail instead of several disconnected tools. Rules update centrally too, so a new sanctions list or an internal policy change reaches every verification flow at once rather than per channel. Case handling stays inside the platform: alerts, notes and decisions attach to the same profile your operations team already works in.

All sensitive data is encrypted at rest and in transit. Role-based access control, audit trails and data change alerts provide comprehensive security monitoring. In practice an operator sees only the fields his role allows, and any manual change to a client record leaves a trace an administrator can review, including who made the change and when. Cardholder data additionally sits under Cryptex DB tokenization with AES-256 encryption, which limits exposure even if a peripheral system is compromised. Administrative actions on sensitive data are logged the same way, so the audit trail covers staff and system activity in one place. For a compliance officer this turns data protection from a set of policies into something provable on demand.

Both SOAP and RESTful APIs are available for all platform functions - payments, accounts, cards, compliance and integrations. Every back-office action you see in the admin UI has an API equivalent, so you can automate account opening, card issuance, transfers, limits and reporting from your own systems without touching the console. Responses are structured for core banking integration work, and message formats can be aligned with ISO 20022 conventions where your partners or the market require it. A typical setup: your CRM opens the account over REST, the core posts incoming payments in real time, and nightly reconciliation runs as a scheduled API job. The endpoint reference is in the platform features section.

Smartex Money runs on MySQL/PostgreSQL with standard Java EE infrastructure. No proprietary storage engines are hidden underneath, which keeps the stack familiar to any Java operations team: standard clustering, standard replication, standard monitoring hooks. Capacity planning is ordinary MySQL/PostgreSQL work as well - your DBA reads the same statistics, slow-query logs and replication lag views they already know from other systems. Under a Life Time License you also receive the source code, so your own developers can audit or extend the system instead of waiting on a vendor. Deployment targets span on-premise, private cloud and public cloud, and the same codebase moves between them - the ABS core banking page outlines the options.

Yes. The Flow Modeler provides visual workflow automation for connecting to banking networks (SWIFT, SEPA), card gateways, KYC providers and government systems. You draw the integration flow - triggers, transformations, error branches - instead of hand-coding each connector, and changing a flow does not require a core release. A typical scenario: incoming SEPA Instant payments are parsed, screened against sanctions lists and posted to customer accounts automatically, with failures routed to an operator queue rather than dropped. The same pattern covers outgoing payment files, card gateway handoffs and KYC vendor callbacks, which keeps the whole exchange layer visible in one designer. The add-on behind it is described on the add-ons page.

SOAP and RESTful APIs for all functions. Coverage matches the detailed answer above: payments, accounts, cards, compliance and integrations are all scriptable, which is how most clients wire the platform into an existing core banking system or into partner services. The same key set can run a full operating cycle - open the day, process transfers, pull statements, close - without anyone opening the admin console. If you already maintain an integration elsewhere, the same endpoints apply to this platform profile.

Flow Modeler connects to SWIFT, SEPA, card gateways, KYC providers, government systems. You build the flows visually and adjust them without redeploying the core, so adding a new KYC vendor or a second card gateway is a configuration task rather than a release. The same editor defines the happy path and the error branches, which is where hand-built integrations usually age badly. That keeps the integration landscape legible for the ops team, not only for the developers who built it, and no middleware layer is required in between.

A white label fintech platform with 50+ core modules and an add-on ecosystem for digital banking and payments. The core covers accounts, payments and cards, while add-ons extend it with a mobile app, reporting, workflow automation, CRM onboarding and SSO. Because everything ships from one vendor, the white label setup stays consistent across web, API and mobile channels instead of fragmenting into per-channel products. For procurement this matters as well: one vendor agreement, one support channel and one security review instead of one per vendor. Single-vendor consistency also keeps upgrade paths clean, since one release train carries the core and its add-ons together.

Mobile App, Report Server, Flow Modeler, On-Board CRM, Cryptex DB, ADS Engine, Smartex SSO. Each one attaches to the core without custom development: the Mobile App adds branded native clients, Report Server handles central reporting, On-Board CRM manages onboarding, Cryptex DB secures card data, ADS Engine runs campaign automation and Smartex SSO unifies access across back office and channels. You can enable them per project as your product grows, and retire one without surgery when a product line closes. That way the platform grows with the product rather than ahead of it.

SaaS: 2-4 weeks. Custom: 2-6 months. The SaaS window holds when the scope is a standard digital banking or payments launch - accounts, cards and transfers under your own brand, with our team carrying the infrastructure. In practical terms that is configuration and user training followed by the cutover itself. Custom projects take longer because of source-level changes, unusual integrations or on-premise infrastructure work. We recommend treating the first release as a pilot and keeping the heavy tail of requirements for phase two.

Yes - branding, workflows, fees, compliance, integrations, the mobile app. Short version: the same customization depth described above applies to every project, from a color scheme swap on SaaS to source-level product logic under a Life Time License. What changes is who maintains the change later, and that is usually the deciding factor between the two models. Most teams start with branding and tariffs on SaaS and revisit deeper changes once the first version is live with real customers.

SaaS = monthly subscription with cloud. Life Time = one-time fee, on-premise, source code. Choose SaaS to validate a market quickly with minimal upfront spend; choose Life Time when regulators, shareholders or your own IT strategy require the system in-house. The licensing model does not change the feature set, it changes who operates it - and that decision shapes your staffing, not just your invoice. SaaS converts capital expenditure into a predictable operating line, while Life Time concentrates spend at the start. Several of our clients run both at once - SaaS for a new brand or market test, on-premise for the established book of business.

On-premise, private cloud, public cloud (AWS/Azure/GCP), hybrid. The choice usually follows licensing and data-residency requirements: a regulator may require that core banking data stays in-country, which points to on-premise or private cloud, while a startup on SaaS stays on our managed cloud. Hybrid setups are common as well - core on-premise, mobile and web channels in the cloud - and the platform runs the same codebase on each target. Operational tooling follows the same Java EE conventions on every target, so monitoring and backup runbooks stay portable. Moving between targets later is a supported project, not a rewrite.

Yes - banking, EMI, PSP and VASP licenses across jurisdictions. The package covers structure analysis, document preparation and interaction with the regulator, with crypto-asset activity mapped to MiCA where the EU regime applies. A typical sequence: jurisdiction shortlist, corporate structure, document pack, regulator dialogue - and the platform work runs in parallel rather than after approval. Compliance expectations do not stop at the license itself, so the same work ties into PSD2 alignment and your AML/KYC procedures, which is what regulators actually test during onboarding. Details are on the fintech licensing page.

Contact us via the website or at smartex@paymart.eu. Tell us which market you cover and which services you already sell - implementation, integration or consulting experience all fit the program. After a short call we agree on a partnership level, register you in the partner program and hand over the first sales materials. From that point on, communication runs through the partner program rather than one-off emails. The program is aimed at teams that already sell to banks, PSPs or fintech companies in their region.

It depends on partnership level and deal size; contact us for details. As a rule of thumb, the more of the project lifecycle a partner covers - from sourcing to implementation to first-line support - the larger the share of contract value that stays with them. Recurring SaaS deals can carry ongoing commission rather than a one-off payout, which is worth negotiating up front when the deal is long-term. Commission terms belong in the partner agreement before the first joint project starts.

Yes - platform, sales methodology and technical fundamentals. Training covers a demo environment where your team runs the core banking scenarios end to end, plus materials for the first customer conversations. Refresher sessions follow major platform releases so partners stay current on new features, and technical onboarding for implementation partners goes deeper into the integration layer. The goal is simple: partners who complete it run demos without our engineers on the call.