Wise Clone · Features

Wise Clone Features: Every Corridor Is Its Own Product

Cross-border money is not one problem solved once. Each corridor has its own rails, its own settlement time, its own compliance expectations and its own cost - and a platform that treats them uniformly is one that works for the first route and struggles with the second. Here is what ships, grouped by who touches it.

Request a Live Demo →See Pricing
5 roles, multi-role access
SEPA and SWIFT-alternative rails
6 days to deploy
Each corridor
Own economics
What a Transfer Passes Through
01Sender KYC, recipient checks
02FX rate engine quotes the rate
03Corridor decides the rail
04AML and fraud screening
05Monitoring, approval if flagged
06Settlement and reconciliation
5
Roles With Scoped Access
3
Rail Types: SEPA, SWIFT-Alt, Local
99.9%
Uptime SLA Target
6
Days to Deploy
By Role

Feature Set by Role

Five roles with scoped access, because a cross-border platform is operated by a compliance team as much as it is used by a customer.

P

Personal Sender

  • Multi-currency wallets with balances per currency
  • Global transfers with the rate quoted before sending
  • Recipient management with saved beneficiaries
  • Physical and virtual cards
  • Payment links and payment requests
  • Activity tracking with transfer status
  • Statements and downloadable records
  • Account-level security controls
B

Business Customer

  • Business wallets and multi-currency receivables
  • Invoicing and payment collection
  • Payroll and bulk transfer runs
  • Spend controls and expense workflows
  • Vendor and payables management
  • Teams with role-based permissions and invitations
  • Approval workflows on outbound money
  • Operational reporting and statements
C

Compliance Operator

  • KYC and KYB submission review
  • Verification rules enforced centrally
  • Fraud and risk flags with policy enforcement
  • Transaction monitoring in real time
  • Approval intervention where rules require review
  • Higher-risk event response workflows
  • Audit trail across every decision
  • Regulated workflow management
F

Finance and Platform Operator

  • Fee logic configuration per corridor and flow
  • FX rate engine and spread control
  • Settlement, reconciliation and refunds
  • Wallet and platform finance visibility
  • Revenue and analytics dashboards
  • Branding, feature access and operational modes
  • Organisation, teams and access governance
  • API keys, webhooks and partner access

Four surfaces are shown here and the platform supports five roles - the fifth being scoped support access. That separation matters: in a regulated money business, the person answering a customer query should not be able to approve a flagged transaction.

Compare

Wise vs Miracuves Clone vs Building From Scratch

The same capability, three different paths. The rows that separate them are corridor rows and compliance rows.

CapabilityOriginal WiseMiracuves CloneGeneric payments script
Rails per corridorLocal rails almost everywhereSEPA, SWIFT-alternative rails and a correspondent banking network, selected per corridorOne rail, usually SWIFT, for everything
FX rate engineMid-market plus transparent feeA rate engine with operator-set spread, quoted to the sender before they commitA static rate table updated manually
KYC and KYBExtensive, per jurisdictionBoth, as reviewable submissions with enforced verification rulesKYC only, if present - businesses unsupported
Transaction monitoringReal-time, at scaleReal-time monitoring with intervention where rules require reviewReports run after the fact
Fraud and risk policySophisticatedFlagging with policy enforcement and higher-risk event responseAbsent
Business collectionsYesInvoicing, payment links, payment requests and receivables trackingSend-only
Payroll and bulk transfersYes, for businessPayroll runs and bulk transfers with approval workflowsOne transfer at a time
Partner accessPublic APIAPI, webhooks and partner access with governance and auditabilityNo API, or an undocumented one
Source codeNot availableComplete Node.js and Flutter source at handover, rebrandedOften encrypted or licence-checked

Row one is the structural difference. Sending everything over a single rail is simple and expensive; selecting the rail per corridor is what makes the economics work, and it has to be modelled rather than hardcoded.

End to End

How It Works, End to End

One cross-border transfer, traced through every check, every rate decision and every record it produces.

01

The sender is verified before they can send

KYC for individuals, KYB for businesses, submitted and reviewed against verification rules enforced centrally rather than judged case by case. In a money-movement business this is the gate everything else depends on, so it precedes the wallet rather than following it.

02

The rate is quoted before commitment

The FX rate engine produces a rate with your configured spread applied, shown to the sender before they confirm. That transparency is the entire proposition in this category - a customer leaving a bank is leaving because the rate arrived after the decision.

03

The corridor selects the rail

SEPA within its zone, SWIFT-alternative rails or the correspondent banking network elsewhere, and local payment infrastructure where available. Different routes settle at different speeds and costs, and choosing per corridor rather than uniformly is where the margin actually comes from.

04

Screening runs before the money moves

AML checks and fraud controls apply to the transfer, the sender and the recipient. A transfer that trips a rule is held for review rather than sent and investigated afterwards - the order matters, because recalling a completed cross-border payment is far harder than pausing one.

05

A compliance operator intervenes where required

Flagged transactions surface in transaction monitoring for approval, rejection or escalation, with the decision recorded. This is a role with its own permissions precisely so that the person reviewing risk is not the person handling the customer.

06

The recipient is paid, the sender is told

Settlement completes over the chosen rail, the recipient receives funds in their currency, and the sender sees status throughout rather than after. Statements and records are generated on both sides.

07

Finance reconciles, and the fee logic proves out

Settlement records, fee logic and refunds reconcile in the finance console, with revenue and analytics showing which corridors actually earned. On a business where margin is thin and per-corridor, that reporting is how you learn which routes are worth keeping.

Steps four and five in that order are the ones that separate a remittance platform from a payments script. Screening after settlement is not compliance, it is reporting.

Deliberate

Every Feature Earns Its Place

Feature lists are cheap. These exist because a specific thing goes wrong in cross-border payments without them.

CapabilityWhy it is not optional
Rail selection per corridorBecause SWIFT for everything is simple and expensive. The margin in cross-border comes from routing each corridor over the cheapest rail that meets its speed expectation, and that requires the corridor to be a modelled concept rather than a destination field.
A rate quoted before commitmentBecause the entire reason a customer leaves a bank is that the bank told them the rate afterwards. A platform that cannot quote before confirmation has no proposition in this category.
Operator-set FX spreadBecause the spread is the primary revenue line and it differs by corridor. Hardcoding it means every pricing change is a deployment.
KYB as well as KYCBecause businesses are the higher-value customers in cross-border, and verifying a company is a different process from verifying a person. A platform with only KYC cannot serve them.
Screening before settlementBecause recalling a completed cross-border payment ranges from difficult to impossible. Holding a suspicious transfer costs a customer some delay; releasing one costs considerably more.
Real-time transaction monitoringBecause after-the-fact reports satisfy nobody. Monitoring that can intervene is what a regulator means by monitoring.
Separate compliance roleBecause the person reviewing a flagged transaction should not be the person under pressure to keep a customer happy. Role separation is a control, not an org chart preference.
Payment links and requestsBecause business collections are inbound money, and a send-only platform serves half the business customer's need.
Payroll and bulk transfersBecause paying forty contractors individually is the problem a business is trying to solve, and doing it one transfer at a time is not a solution.
Per-corridor revenue analyticsBecause in a thin-margin business with different economics per route, blended reporting hides the corridors that lose money.

Half of these are compliance controls and half are corridor economics. Those two things are what cross-border payments actually is, underneath the interface.

Stack

The Technology Behind the Features

Choices made for auditability and integration rather than novelty.

BackendNode.js with Express and TypeScript in a modular, microservice-friendly API layer covering banking, business, risk and admin operations - auth, accounts, transactions, cards, FX, notifications and controls.
FrontendFlutter for cross-platform Android and iOS from one foundation, with React and Next.js responsive dashboards for retail, business and admin, and role-aware journeys across all of them.
DataPostgreSQL for accounts, wallets and user data, with structured handling of transactions, ledgers and payments, and indexing tuned for statements, feeds and reconciliation.
Money movementA multi-currency wallet, an FX rate engine, payment gateway integration, SWIFT-alternative rails, SEPA transfer capability and a global correspondent banking network behind the corridor layer.
IntegrationAPI, webhooks and partner access built for auditability and operational control - which is what makes embedded-finance and partner-led models possible rather than bolted on.
GovernanceRole-based permissions, teams and invitations, organisation-level access governance, and an audit trail across compliance decisions.

Why the corridor has to be a first-class concept

The temptation in cross-border software is to model a transfer as a source, a destination and an amount, then pick a rail at send time. That works until the second corridor, at which point everything that differs by route - the rail, the settlement time, the fee structure, the compliance expectations, the correspondent relationship - has nowhere to live except in conditionals scattered through the code. Making the corridor a modelled thing with its own rail, fee logic and rules is what lets you add Kenya without touching how the Philippines works.

Node + TSTyped API layer
PostgreSQLLedgers and transactions
SEPA / SWIFT-altRail options
API + webhooksPartner access

Complete source transfers to you at handover, with rebranding and white-labelling included.

Honest Readiness

What Is Not Included in the Base Package

Everything above ships in the ready-made platform. These sit in the Enterprise tier or belong to you - and in a regulated money business the second list decides whether you can operate at all.

Enterprise scope, or yours to own

  • Money transmission licencesCross-border money movement is regulated in every jurisdiction on both ends of every corridor. Whether you hold the required licences, or operate under a licensed partner, is entirely yours - and it determines which corridors you may serve before any technical decision does.
  • Correspondent and partner relationshipsThe platform supports SEPA, SWIFT-alternative rails and a correspondent network. Being accepted by those partners, and the terms you get, is a commercial negotiation you own - and it is what actually determines your cost per corridor.
  • Named KYC, AML and screening vendorsKYC, KYB, AML and fraud workflows ship. Integrating a specific identity, sanctions-screening or transaction-monitoring provider is Enterprise scope.
  • Nostro funding and liquidityPre-funding accounts in destination currencies so transfers settle quickly is a treasury function requiring real capital. No software supplies it, and it is often the largest working-capital commitment in the plan.
  • Advanced finance modulesCrypto rails, forward contracts and hedging tooling are named on the hub as premium monetization layers - Enterprise scope rather than base build.
  • Enterprise rollout timelinesThe hub is explicit that Enterprise deployments are 15+ days for standard rollouts rather than six, because regulated and partner-led configurations involve more than configuration.
  • Compliance programme and staffingThe platform provides the control and evidence layer. Your policies, regulatory reporting and the qualified people running them are yours.
  • ISO 27001 and SOC 2Neither certificate is held and neither is claimed.

Licensing and correspondent relationships are the two that decide your product. A corridor you cannot legally serve, or cannot get a partner for, is not a configuration problem - so map those before you map features.

Development Company

See how Miracuves compares to agencies and freelancers

The deployment process, named fintech deployments, and what to verify on screening order and reconciliation before you hire anyone.

See the comparison →
FAQ

Frequently Asked Questions

How are different corridors handled?
The corridor is a modelled concept rather than a destination field, with its own rail, fee logic and rules. SEPA within its zone, SWIFT-alternative rails or the correspondent banking network elsewhere, and local infrastructure where available. That matters because routing everything over one rail is simple and expensive - the margin in cross-border comes from picking the cheapest rail that meets each corridor's speed expectation.
Is the rate shown before the customer commits?
Yes - the FX rate engine quotes with your configured spread applied before the sender confirms. That is the whole proposition in this category: a customer leaving a bank is leaving because the bank told them the rate after the decision. A platform that cannot quote up front has nothing to differentiate on.
Does it support businesses as well as individuals?
Yes, and businesses are usually the higher-value customers here. KYB sits alongside KYC as a separate verification process, and business customers get invoicing, payment collection, payroll and bulk transfers, spend controls, vendor management, teams with scoped permissions and approval workflows on outbound money.
When does compliance screening happen?
Before settlement, not after. AML and fraud checks run on the transfer, sender and recipient, and anything that trips a rule is held for review rather than sent and investigated later. That ordering is deliberate: pausing a suspicious transfer costs a customer some delay, while recalling a completed cross-border payment ranges from difficult to impossible.
Do I need a money transmission licence?
Almost certainly, or you need to operate under a licensed partner. Cross-border money movement is regulated on both ends of every corridor, and what you may legally serve is determined before any technical decision. The platform supplies the control and evidence layer that those conversations require - it does not supply permission.
Is there an API for partners?
Yes - API, webhooks and partner access are in the base build, designed for auditability and operational control rather than added later. That is what makes embedded-finance and partner-led models workable, and it is also a revenue line in its own right: programmable access sold as subscriptions or integration-led services.

Send a transfer that trips a rule

That is the demo worth asking for. Watch it hold, then approve it as a compliance operator and see the record.

Ready to launch a cross-border money platform?

Deploy in six days with multi-currency wallets, an FX rate engine, SEPA and SWIFT-alternative rails, KYC, KYB, AML and fraud controls, and full source on infrastructure you own.

Talk to Us →
Miracuves · Wise Clone Solution Feature set and Enterprise-tier caveats cross-verified against the live hub, 2026-08-21
Disclaimer

Miracuves is an independent software development company. We are not affiliated with, connected to, sponsored by, or endorsed by Wise.

Why this name

Wise Clone” is used descriptively. It is how the software industry refers to building a platform with functionality similar to Wise, and how clients search for it.

Who built this

The entire design and codebase is built by our own team. The product contains no code, design, graphics, or content originating from the Wise website or applications.

Trademarks

Wise and all other third-party names and marks are the property of their respective owners, referenced here solely to describe the category of software offered.