Every Western Union transfer carries an MTCN — getting the ledger behind it

What the transfer ledger actually holds

Every money transfer the app creates is keyed by a ten-digit Money Transfer Control Number. Western Union's own help material confirms the MTCN is stored in the app's transfer history and is what a sender or receiver uses to follow a payment. That makes the MTCN the natural primary key for any integration here — but it returns only the public-facing state. The amounts, the locked exchange rate, the fee and tax breakdown, the payout method and the receiver sit behind the authenticated sender account, in the same history list the user sees in the app.

So there are two surfaces in play: a per-transfer status reachable by MTCN, and a richer per-account history reachable only inside a logged-in session. A useful integration joins them. The table below is what we map for this app, not a generic finance checklist.

Reading a transfer by its MTCN

This is the shape of the work, not a contract you can call today. Field names are normalized on delivery; the structure below is the kind we confirm during an authorized protocol-analysis build run against a consenting account.

# Illustrative. Shapes confirmed during the build, not a published interface.

POST /mobile/v3/auth/token
  { "username": "...", "secret": "...", "device_id": "<bound device>" }
  -> 200 { "access_token": "...", "refresh_token": "...", "expires_in": 900 }

GET  /mobile/v3/transfers?scope=all&limit=50
  Authorization: Bearer <access_token>
  -> 200 {
       "transfers": [
         { "mtcn": "1234567890",          # 10-digit control number
           "state": "AVAILABLE",          # IN_REVIEW|AVAILABLE|PAID|REFUNDED|ON_HOLD
           "send":   { "amount": 300.00, "currency": "USD",
                       "fee": 4.99, "tax": 0.00, "fx_rate": 17.05 },
           "payout": { "method": "CASH", "currency": "MXN",
                       "amount": 5103.00, "agent_country": "MX" },
           "receiver": { "name": "...", "ref": "..." },
           "created_at": "2026-05-12T14:03:00Z" } ] }

GET  /mobile/v3/transfers/{mtcn}/status
  -> 200 { "mtcn": "1234567890", "state": "PAID", "paid_at": "..." }
  -> 401 token expired        -> refresh once, replay
  -> 404 mtcn not on account  -> surface as not-found, stop retrying
      

The state field is the part teams underestimate. A transfer is not done when it is created; it moves through review, becomes available, gets paid, and can be refunded or held. A correct sync follows that machine and stops polling once a transfer reaches a terminal state.

What you receive at handover

The deliverable is a working client for the two surfaces above, plus the paper that lets your team own it:

• An OpenAPI description of the transfer-history and MTCN-status endpoints as we observed them, with the normalized field names you will actually code against.
• Runnable source in Python or Node — login, token refresh, paginated history pull, single-MTCN status lookup, and the state-machine handling so completed transfers stop being re-polled.
• An auth-flow report: the token and refresh chain, device binding, and the step-up points, written so a new engineer can re-derive it.
• Automated tests against recorded fixtures, including the 401-refresh and 404-not-on-account paths.
• Interface documentation and a data-retention note covering what is pulled, what is stored, and what is minimized.

Each item is tied to a real surface of this app — the history list, the MTCN status, the quote and disclosure fields — not a template stub.

Routes to the data, and the one we build on

Four routes apply here. They are not equal.

Authorized protocol analysis of the app's traffic

The app's own mobile session is where the full history and the live state live. Under your authorization we map the traffic, document the auth and the endpoints, and build a client against them. Reach: the whole transfer ledger. Effort: moderate. Durability: good, with the canary check described below. Access is arranged with you during onboarding, against a consenting account or a sandbox you nominate.

User-consented account session

For a product where your own users connect their Western Union account, the integration runs on their consent and their session. Reach is the same as above; the difference is whose authorization carries it. This pairs with route one rather than competing with it.

Regulated data-rights backstop

In Europe a GDPR subject-access request returns the held records; in the US the Regulation E remittance rule entitles the consumer to receipts and the records behind them. These are slower and not real-time, but they are a lawful fallback when a live session is not available, and they anchor the compliance story. Where the same person also holds a Western Union Digital Banking (WU+) account, that account is inside a licensed credit institution and a consent-based account-information path can apply to it.

In-app capture as a thin fallback

The receipt and the on-screen history can be captured directly where nothing richer is reachable. It is the weakest route and we use it only to fill gaps.

In practice we build on routes one and two together: the authenticated session plus the app traffic returns the full history and the live status, which is what almost every caller needs. The data-rights route is the regulated backstop, not the primary feed.

Disclosure rules and the consent that governs access

This is a remittance provider, so the rule that actually shapes the data is the CFPB's remittance transfer rule under Regulation E. It requires a pre-payment disclosure and a receipt carrying the fee, tax, exchange rate and the amount the receiver gets — which is why those fields exist as discrete values worth capturing. It also gives the sender, per the CFPB, roughly 180 days to assert an error and the provider about 90 days to investigate; an integration that reconciles transfers should respect that window rather than treat a recent transfer as final. In Europe, Western Union International Bank is a licensed credit institution supervised by the Austrian Financial Market Authority, and the group's GDPR posture — including a documented subject-access channel — is what the data-rights route relies on. We operate access as authorized, logged, consent-recorded and data-minimized, with an NDA where the engagement needs one. Compliance here is how we work, not a gate you clear before we start.

Engineering notes for a remittance ledger

Three things about this specific app shape the build, and we handle each:

• The MTCN is a stable key but state is not — we model the transfer state machine so the sync captures terminal states (paid, refunded) and stops polling a settled MTCN instead of hammering it.
• Quote fields are corridor-specific and disclosed per the remittance rule — we store the disclosed amount, fee, tax and locked FX rate as separate columns so a reconciliation matches the receipt the sender saw, not a rate recomputed after the fact.
• The session is a device-bound mobile login with step-up checks — we build token refresh and re-auth into the client so a long-running history pull does not silently drop, and we keep the public agent directory on its own refresh cadence because it is reference data, not per-user.

Three integrations teams actually ask for

• Payout reconciliation. A business sending payroll or supplier remittances pulls the history nightly, matches each MTCN to its own ledger, and flags any transfer not in a paid state past its expected window.
• Status notifications. A consumer product that lets users link their Western Union account watches transfer state and pushes "available for pickup" or "paid" events into its own messaging, instead of asking users to re-check the app.
• Corridor analytics. A finance team aggregates the disclosed fee, tax and FX fields by payout country and method to compare effective cost across cash, bank and mobile-wallet corridors.

Freshness, retries, and what breaks on an app update

Live status is near real-time off the session; history is as current as the last authenticated pull. Retries are bounded — a 401 triggers one refresh-and-replay, a 404-not-on-account is terminal and not retried. When Western Union ships a new app build, the risk is a quiet contract change. We keep a snapshot of the request and response shape and a monitored canary lookup against a known transfer, so a change shows up as a failed check we act on, not as drift you discover in a reconciliation weeks later.

Other money-movement apps in the same scope

The same integration approach covers the broader remittance and cross-border payment category. Named here for context, not ranked:

• Remitly — digital remittances to many countries; per-user transfer history and recipient records behind an account.
• Wise — multi-currency balances and transfers; rich authenticated statement and FX data.
• WorldRemit — bank, cash, mobile-money and airtime payouts with per-transfer status.
• MoneyGram — cash and digital transfers with a tracking reference much like an MTCN.
• Xoom — PayPal's remittance service; account-held transfer and payout history.
• Ria Money Transfer — global cash and bank payouts with a tracking-number ledger.
• Revolut — multi-currency account, card and transfer activity behind an authenticated session.
• Paysend — card-to-card and account payouts with per-transfer state.

A unified integration normalizes transfer, status and payout records across these so one schema serves several providers.

Sources checked for this mapping

Checked in May 2026: Western Union's MTCN help page for how the control number is stored and used in the app; the CFPB's remittance transfer rule and its Regulation E error-resolution procedure for the disclosure and dispute mechanics; the Data Rights Finder entry for the group's GDPR subject-access posture; and Western Union International Bank's own page for its credit-institution status under the Austrian FMA. App surfaces are taken from the current Play listing (package com.westernunion.moneytransferr3app.acs4, per that listing) and the app's own description.

• Western Union — what an MTCN is and where it appears
• CFPB — remittance transfer rule (Regulation E)
• CFPB — § 1005.33 procedures for resolving errors
• Data Rights Finder — Western Union GDPR subject access
• Western Union International Bank — credit-institution status

Mapped by the OpenBanking Studio integration desk · May 2026.

Questions integrators ask about this app's data

Is an MTCN enough to reconstruct a transfer, or do we also need the sender's session?

The MTCN identifies one transfer and returns its public-facing state, but amount sent, fees, taxes, the locked FX rate, payout method and receiver detail live behind the authenticated sender account. We build the client to use both: the MTCN as the natural key and the consented session for the full record.

Does open banking or PSD2 cover a Western Union remittance the way it covers a bank account?

A consumer-to-consumer remittance booked through a money services business is not a PSD2 payment account in the usual account-information sense, so the working feed is authorized protocol analysis plus a consented account session. Regulated data-rights routes are the backstop: a GDPR subject-access request in Europe, Regulation E remittance records in the US. Where the same person also holds a Western Union Digital Banking (WU+) account, that one sits inside a licensed credit institution and a consent-based account-information path can apply to it.

Can the export separate cash-pickup transfers from bank-deposit and mobile-wallet ones?

Yes. Payout method is part of each transfer record — cash at an agent, deposit to a bank, or a mobile-money wallet — so we normalize it as its own field and you can filter or reconcile by corridor and payout type.

How do you keep the client working when Western Union ships a new app build?

We keep a snapshot of the request and response contract and a monitored canary lookup against a known transfer, so an app-version or front-end change shows up as a failed check we act on rather than as silent drift in your data.

Working with us on this

A finished build here is a documented client for the transfer-history and MTCN-status surfaces — runnable Python or Node, an OpenAPI description, the auth-flow report and tests. Source-code delivery starts at 300 USD and is paid only after you have the code and it runs to your satisfaction. If you would rather not host it, the same endpoints are available as a pay-per-call hosted API with nothing paid upfront — you are billed for calls, not a setup fee. Either path runs on a one-to-two-week cycle. Tell us the app and what you need from its data at /contact.html, and access and any compliance paperwork are arranged with you from there.