Cross-Border Remittance App Architecture: KYC, AML, and Payment Gateway Costs

A customer sends money, the funding provider reports success, and the payout provider times out. Has the recipient been paid? Can the application retry? Can support issue a refund? If the architecture cannot answer those questions without guessing, a polished exchange-rate screen is concealing the most expensive part of the product.

This guide helps founders and procurement teams scope a cross-border remittance application before commissioning development. It separates identity checks, risk decisions, funding, foreign exchange, payouts and financial reconciliation. It is technical procurement guidance, not legal advice or an assurance of regulatory approval. All numerical examples are fictional budgeting inputs. Licensing, permitted activities and local obligations require qualified review for each corridor and business model.

Establish who is legally moving the money

Start with the operating relationship, not the programming language. Is your company a licensed operator, an agent, a technology supplier or a customer-facing application working with an authorised partner? Which entity contracts with the sender, receives funds, executes conversion and pays the beneficiary? Those answers determine the product boundary and the evidence your partners will require.

Prepare a corridor register naming origin, destination, currencies, customer type, funding method and payout method. Identify the responsible regulated entity and production approval status for each combination. A partner supporting one bank-transfer corridor does not establish support for cash payout, business customers or every country appearing in a dropdown.

The FATF Recommendations provide an international framework implemented through national measures. They are not a universal licence or an integration checklist that overrides local rules. Have the appropriate legal and compliance owners translate applicable requirements into product decisions. Engineering needs approved rules, required records, escalation responsibilities and a change process. It should not invent eligibility rules simply because an API permits a request.

Model six related workflows instead of one status

Customer verification, risk review, funding, exchange quotation, payout and reconciliation have different lifecycles. Keep their identifiers and state histories separate. A customer may be verified while a particular transfer remains under review. A transfer may be funded while a beneficiary account requires correction. A payout request may be accepted without final confirmation of receipt.

For a fictional flow, the application collects the transfer intent, obtains a quote, checks eligibility, confirms funding, submits the approved payout and reconciles the result. Each transition records its cause and the evidence available at that time. The precise sequence depends on partner contracts and the corridor; it should not be copied blindly from a generic diagram.

Expose a customer-friendly summary without destroying operational detail. Processing can be a reasonable customer label while support sees awaiting funding, risk review or payout acknowledgement. Document which states permit cancellation and which require investigation. Avoid a single success flag used simultaneously by checkout, accounting and support. It makes contradictory evidence hard to represent and encourages unsafe retries when external systems disagree.

Treat KYC as a configured decision process

An identity provider can collect documents and return verification results, but your operating policy still determines what is required and what happens next. Define the relevant customer types, permitted documents, verification levels, retry rules and review paths with the responsible compliance function. Keep policy versions so a later reviewer can understand the rule applied at onboarding.

Sumsub's integration documentation describes applicant creation, verification configuration and results delivered through webhooks. Those are implementation components, not proof that every applicant should automatically receive transfer permission. A technical integration should distinguish not started, awaiting submission, provider processing, review required and a final decision according to the approved policy.

Minimise duplicated identity data. Where the contracted model permits, retain provider references and necessary decision evidence rather than copying every raw document into several internal systems. Define access, retention, deletion and vendor-exit arrangements before launch. Test rejected documents, interrupted capture, changed personal details and delayed results. The happy-path SDK demonstration does not reveal how much operational work exceptions will create.

Budget identity checks using billable events

A per-check headline does not tell you the monthly invoice. Ask whether the contract bills applicants, individual checks, verification bundles, ongoing monitoring, document extraction or repeated attempts. Include monthly minimums, setup costs, support tiers, taxes and currency. Request written clarification for abandoned sessions, re-verification and manual review rather than inferring those terms from a sales page.

Sumsub's billing documentation describes reporting by check type, quantity and price, with contractual plan details. Use that reporting model to build an internal reconciliation worksheet. For Jumio or another supplier, request a proposal for the same document types, jurisdictions, volumes and service commitments. This guide deliberately does not invent a universal Jumio rate or treat a different provider's public package as an equivalent quote.

As fictional arithmetic, two thousand billable initial checks at an assumed two dollars each cost four thousand dollars. Two hundred additional billable checks at the same assumed rate add four hundred dollars. A three-hundred-dollar assumed monitoring allocation produces forty-seven hundred dollars before other exclusions. None of those values represents a current provider tariff. The example shows why retries and monitoring belong in the forecast.

Keep AML and sanctions decisions reviewable

Identity verification is not the whole risk programme. Depending on applicable rules and partner responsibilities, the operating model may require screening, transaction monitoring, enhanced review and reporting workflows. Document who configures the controls, who reviews potential matches and who has authority to release a transfer. Do not describe a green identity badge as automatic AML compliance.

Build a case queue with controlled access, assignment, evidence references, decisions and timestamps. Preserve the distinction between a provider signal and an internal conclusion. A potential match may need investigation rather than an automatic accusation. Customer messages should follow approved policy and avoid exposing sensitive investigation details or information that the operator is not permitted to disclose.

Budget the review operation alongside the API. A fictional three hundred cases requiring eight minutes each represents forty staff hours before quality review or escalation. That is a workload illustration, not a prediction of false-positive rates. Changing corridors or screening thresholds can alter staffing demand. Ask suppliers to explain how rule changes are approved, tested and recorded without rewriting the history of earlier decisions.

Store quotes as commercial records

A quote needs more than a visible exchange rate. Record the source and target currencies, relevant amounts, fees, expiry, provider reference and the customer acceptance event. Clearly distinguish an indicative estimate from a quote that can actually be executed under the partner's terms. Expiry should be enforced by the backend rather than trusted to a browser countdown.

Wise's quote API documentation exposes quote-related data and configuration that can inform an integration design. It is a provider-specific contract, not a universal remittance model. Confirm which endpoints, rate guarantees and funding options apply to your partnership before adopting their behaviour in your own specification. An accessible documentation page does not establish commercial access to that service.

Define what happens if the quote expires before funding completes. The customer may need a new quote and explicit acceptance, or another contractually approved path. Do not silently substitute a different recipient amount. Save the version the customer accepted and the version the provider executed. Support and finance need both when investigating a fee or exchange-rate dispute months after the application screen has changed.

Engineer the ledger before adding more corridors

Use a reviewed financial model with explicit accounts, journal entries and currency treatment. A double-entry design is a common way to make postings balance, but the accounting rules must be agreed with appropriate finance expertise. A ledger cannot be made correct merely by giving two database columns debit and credit names.

Amounts should use a representation appropriate to each currency and operation, with documented precision and rounding. Do not assume every currency has two decimal places or use binary floating-point arithmetic indiscriminately for posted money. Currency conversion requires balanced treatment and traceable exchange references, not adding unrelated currency amounts together and calling the result balanced.

Post corrections through controlled reversal or adjustment entries rather than editing financial history invisibly. Distinguish customer obligations, provider receivables, fees and settled cash as the operating model requires. Keep business events linked to financial postings. Budget independent reconciliation and review: an internally balanced ledger can still disagree with actual bank or provider records. The acceptance goal is explainable money movement, not merely the absence of a database error.

Make retries safe when a payout result is unknown

A timeout means the application did not receive a timely answer. It does not prove that the provider rejected the payout. Retrying a money-moving request without an idempotency strategy can create duplicate transfers. Persist the intent and a stable request reference before submission, then recover through the provider's supported lookup and retry behaviour.

Represent unknown outcomes explicitly. An operator should see that a request needs investigation rather than an invented failed state that enables a second payment. Define which operations can be retried automatically, which require status lookup and which need approval. Document provider-specific idempotency scope and expiry instead of assuming all APIs retain keys forever.

Test a response lost after provider acceptance, an application restart before local acknowledgement, and a webhook arriving before the synchronous response. The expected result is one economic transfer with a traceable history. The test environment should make duplicate attempts visible. These scenarios take integration time, but they are far cheaper to address in a sandbox than through emergency manual recovery after real recipients receive duplicate funds.

Design webhooks as one evidence channel

Providers send asynchronous events, often with retry behaviour. Wise's webhook guidance describes callbacks, transfer updates and delivery retries, while noting delivery is best effort. That supports a design with both event handling and periodic status reconciliation, rather than treating one notification as an infallible financial record.

Validate each provider's authentication mechanism, reject unexpected payloads, record a safe event reference and deduplicate repeated delivery. Persist accepted work before acknowledging it. Process changes through permitted state transitions so an old event cannot incorrectly move a completed transfer backwards. Keep payload retention limited and avoid leaking identity documents or payment credentials through diagnostic logs.

A recovery job should identify transfers that have remained unresolved beyond an agreed threshold and query the appropriate authoritative source. The threshold depends on the corridor and partner commitments; it should not be advertised as a universal payout SLA. Give operations a discrepancy queue and a documented escalation route. A webhook dashboard is useful only when someone is responsible for investigating missing or contradictory evidence.

Separate gateway charges from liquidity requirements

Funding fees, payout fees, foreign-exchange economics, verification costs and infrastructure belong in different budget lines. Add partner onboarding, minimum commitments, return fees and support costs where applicable. Clarify which charges apply to failed or reversed transfers. A successful-payment percentage alone is not a full remittance operating model.

Liquidity and prefunding are not software expenses. A partner may require funds to be available before executing payouts, subject to the commercial arrangement. Settlement timing can differ between funding and payout rails. Ask finance to model working capital, safeguarding or other applicable arrangements separately from the development quotation. Software should display the relevant balances and restrictions accurately, not manufacture available funds through bookkeeping labels.

For a fictional transaction, assume a ten-dollar revenue allocation and six dollars of combined partner, verification and support costs. The remaining four dollars is not net profit: staffing, losses, taxes, technology and capital costs may remain. Use such arithmetic only to expose missing lines. A development supplier should not promise profitability from an assumed spread or imply that a technical wallet automatically authorises custody.

Scope the administrative console around controlled actions

Operations needs to locate transfers, explain their state, review evidence and escalate exceptions. Finance needs reconciliations and exports. Compliance needs controlled case handling. Support needs enough information to assist the customer without unrestricted access to identity documents or permission to release money. These roles should not collapse into one administrator password.

Define approval boundaries for changes to beneficiary details, refunds, manual adjustments and risk settings. Sensitive actions may require a second reviewer according to the approved policy. Record the initiating actor, approving actor, reason and resulting provider reference. Use scoped access and secure authentication, and make temporary elevated access expire predictably.

The accompanying image is an illustrative payment-review workspace, not a remittance demo or evidence of regulated capability. A real procurement demonstration should show the intended approval controls with synthetic data. Ask whether a rejected action leaves an audit event, whether an export respects role restrictions and whether a reviewer can approve their own request. These details reveal the difference between a case-management interface and a trustworthy operational workflow.

Build an implementation estimate around risk-bearing work

The worksheet uses invented allowances of eighty hours for discovery and corridor mapping, one hundred twenty for identity and review workflows, one hundred eighty for the ledger, one hundred sixty for funding and payout integration, one hundred twenty for operations and reconciliation, and one hundred eighty for testing and handover. The total is eight hundred forty hours.

At an assumed fifty dollars per hour, that would mean forty-two thousand dollars of implementation labour. It excludes licences, legal advice, regulatory applications, provider charges, capital, infrastructure, independent assurance, taxes and contingency. It is not a quote or a minimum investment for a regulated business. Provider onboarding and approval delays also cannot be converted directly into developer hours.

Ask bidders to attach assumptions to every workstream. Which corridors are included? Which provider accounts are available? Who supplies the compliance policy and accounting model? What happens when a production API differs from the sandbox? A smaller feature list may lower effort, but removing duplicate-payment prevention or reconciliation is not an acceptable way to make a financial product appear inexpensive.

Define release gates that include the partners

Sandbox success proves only the scenarios exercised in that environment. Production readiness also depends on contracted access, approved corridors, configured limits, funding arrangements, operational staffing and provider escalation routes. Require named owners and documentary evidence rather than an ambiguous ready-for-live status in a project tracker.

Use synthetic cases to test rejected verification, held transfers, insufficient prefunding, expired quotes, unknown payouts, duplicate events and returned funds. Confirm the accounting result and customer message for each. Have the relevant finance and compliance owners review the evidence. Security testing should include access boundaries, secrets management, administrative actions and data exposure, not just a scan of the public homepage.

Agree a controlled launch envelope and a stop condition. A pilot may restrict customer eligibility, transaction limits and supported corridors according to approved policy. Define what pauses new transfers while allowing existing obligations to be resolved. Rolling back an application version does not reverse a bank transfer; operational recovery must address already-submitted requests and preserve their financial history.

Use reconciliation as an operational control loop

Give every transfer a reconciliation position: matched, awaiting external evidence, discrepant or resolved through an approved adjustment. The labels can differ, but the process needs an owner and a deadline. Compare internal postings with the provider statements and relevant bank evidence available under the operating arrangement. A customer-facing completed status should not automatically remove a transaction from financial review.

For a fictional exercise, an internal record shows a one-hundred-unit payout while a provider statement shows a ninety-nine-unit delivered amount and a one-unit fee. The system must explain whether the fee was expected, who bears it and whether the customer disclosure matched. Do not force the records to match by silently changing the original amount. Preserve the discrepancy, investigation and approved accounting response.

Ask finance to define reconciliation cutoffs, currency handling and treatment of late arrivals. A transaction crossing a calendar boundary can appear in different daily reports without being missing. Use consistent references and clearly documented reporting time zones. Export files should identify their generation time and relevant scope so staff do not compare two different reporting windows and mistakenly create a financial adjustment.

Keep exception actions separate from report viewing. Someone who can download a statement does not automatically need authority to write an adjustment or trigger a refund. Sensitive corrections should follow the approved review process. Demonstrate the complete investigation in the sandbox, including the final evidence a second reviewer sees. That workflow deserves an estimate line because it is part of operating the product, not optional analytics.

Plan a provider exit without losing transfer history

Provider replacement is not merely switching an API hostname. Open transfers may still depend on the old partner, identity evidence may have retention restrictions and historical quotes need their original references. Ask how the application continues reconciliation while new transfers use a different integration. Keep provider-specific identifiers namespaced so references from two partners cannot collide.

Agree usable exports and permitted access to retained evidence before signing. Include account closure, credential revocation and unresolved-case cooperation in the exit plan. These arrangements do not guarantee an effortless migration, but they make dependencies visible while you still have negotiating room. A source-code handover alone cannot transfer a partner contract or reproduce external evidence that was never retained lawfully.

Retain a dated integration inventory naming API versions, webhook subscriptions, credential owners and contracted environments. Record deprecation notices and the person responsible for assessing them. A partner API change can affect an otherwise stable application, so maintenance needs an agreed budget and test suite. Before renewing a contract, review unresolved discrepancies and unsupported corridors against the original proposal. That discussion is more useful than comparing the number of endpoints each vendor advertises.

Answer the procurement questions before signing

Can one provider handle everything? Perhaps under a particular agreement, but verify coverage, responsibilities and failure paths rather than assuming a single integration removes all complexity. Can the app launch before licensing is resolved? That requires qualified advice about the proposed activity and relationship; software readiness is not permission to operate.

Is KYC a one-time development item? Integration is an implementation item, while checks, policy maintenance and review operations can recur. Is a double-entry ledger sufficient? No: it must reflect the approved financial model and reconcile with external evidence. Can delivery be promised from a generic feature list? Not responsibly without corridor, partner and acceptance assumptions.

For an App Clone Labs scoping discussion, bring the corridor register, partner contracts or approved integration terms, identity policy, accounting requirements and operational roles. The useful deliverable is a responsibility map, a controlled transfer lifecycle and a budget whose exclusions are visible. Use the linked remittance solution and delivery-process pages to define that boundary before expanding currencies or adding a customer-facing balance feature.

FATF Recommendations: international framework and national implementation

Sumsub billing: check types, usage and contractual pricing

Sumsub API verification integration flow

Wise Platform quote API reference

Wise Platform webhook delivery and retry guidance

Remittance solution planning

Engineering and validation process

Discuss corridor and integration requirements