Getting CROSS: REMIT & SHOP records into your own systems

A CROSS transfer is described as clearing in about five minutes, weekends and holidays included, per the app's own Play Store listing. Every one of those transfers leaves a structured record — sender, beneficiary, corridor, amount in KRW, the fixed fee, the status as it moves to confirmed. That record, plus the points a user accrues and the Cross Shop orders they place, is the material a third party would want to read, sync, or reconcile. This page maps that data and the authorized way we reach it for you.

CROSS is run by CROSS ENF, a Seoul remittance operator founded in 2017 whose app launched in 2019 to serve migrant workers in Korea, per Tranglo's account of the partnership. It built much of its volume through the Tranglo Connect rail — reportedly reaching 24 countries and corridors, with the Philippine corridor cited as a standout. So the data is real-time, cross-border, and per-user. That shapes everything below.

Bottom line: the high-value surface here is the live remittance flow and its ledger, with the points and shop data riding the same authenticated session. We would reach it by mapping the app's own traffic under the account holder's authorization, and hand you runnable code plus a spec — not a slide deck.

What CROSS holds, surface by surface

These map to things the app visibly does. Granularity is what we would expect to recover; we confirm field-by-field during the build.

Reaching the data

Three routes genuinely apply to CROSS. We set up access for each as part of the work, with you.

Authorized interface integration / protocol analysis

We observe and model the app's own client-to-server traffic under the account holder's authorization: the login and token exchange, then the calls that return transfer history, beneficiaries, points and orders. This reaches everything a user can see in the app, including live transfer status. Effort is moderate; durability depends on the app's release cadence, which we handle with a re-validation step. This is the route we would lead with for CROSS, because the remittance ledger and points share one session and a vendor-agnostic protocol map gives you all of it.

User-consented credential access

Where a sender wants their own data pulled, they consent and we run the same flow on their behalf, scoped and logged. Useful for one-off migrations or for a product that aggregates a user's transfers across providers. Lower setup, narrower than a full integration.

MyData / regulated portability

Korea's MyData framework, under PIPA and supervised by the PIPC, is the formal data-portability path for financial data. Coverage for a small-sum remittance operator can be partial, so we treat this as a complement: where a portability channel exists it is the most durable, and we layer the interface integration over the rest. Native in-app export, if present, is a fallback we test for during scoping.

For CROSS specifically, the interface route carries the build; consented access covers single-user pulls; MyData is the durable layer we use wherever it reaches. We pick the mix against your actual goal in the first week.

What lands in your repo

Concrete artifacts, tied to CROSS's surfaces:

• An OpenAPI/Swagger spec describing the transfer, beneficiary, points and order endpoints as we recover them.
• A protocol and auth-flow report: the login, token issuance and refresh chain, session/cookie handling, and how status updates arrive.
• Runnable source for the key calls — Python and Node.js — including a transfer-history pull, a beneficiary fetch, and a points-ledger read.
• Automated tests against recorded fixtures so a CROSS release change surfaces as a failing test, not a silent data gap.
• Interface documentation an engineer can hand to a teammate.
• Data-retention and consent-handling guidance written against PIPA and the Credit Information Act.

A transfer pull, sketched

Illustrative shape, not copied CROSS internals — field names and the auth chain are confirmed during the build.

POST /auth/token            # session bootstrap after KYC'd login
  { device_id, credential_grant }  -> { access_token, refresh_token, exp }

GET  /v1/remittances?from=2026-05-01&limit=50
  Authorization: Bearer <access_token>
  -> {
       "items": [
         { "transfer_id": "...",
           "corridor": "KR-PH",
           "payout_country": "PH",
           "payout_method": "cash_pickup",
           "amount_krw": 500000,
           "fee_krw": 5000,
           "fx_rate": 24.1,
           "status": "completed",      # applied | sent | completed | failed
           "beneficiary_id": "...",
           "applied_at": "...", "confirmed_at": "..." }
       ],
       "next_cursor": "..."
     }

# handle: 401 -> refresh once; empty next_cursor -> end of history
# normalize amount_krw + fx_rate into your own ledger currency

Integrations teams ask for

• A payroll or HR tool for migrant workers that mirrors each employee's outgoing remittances and confirms payout status without manual screenshots.
• A multi-provider money-movement dashboard where a sender's CROSS transfers sit alongside SentBe or WireBarley records in one normalized ledger.
• A loyalty audit that reconciles the daily-accrual and referral points against expected balances to flag anomalies.

Korean rules this runs under

CROSS operates as a small-sum overseas remittance business — its listing cites registration No. 2018-11 — a category registered under the Foreign Exchange Transactions Act and supervised by the Financial Services Commission and Financial Supervisory Service. On the data side, PIPA governs personal information across its lifecycle, the Credit Information Act applies because financial and account data is involved, and the Personal Information Protection Commission is the supervisor. The dependable basis for any pull we run is the account holder's explicit consent; MyData is where formal portability may broaden. We keep consent records, log access, minimize fields to what the integration needs, and work under an NDA where you want one. Compliance is how we operate, arranged with you, not a form you clear before we start.

What we plan for on this build

• We design the sync around real-time status: a transfer can move from applied to completed within minutes, so we poll or hook the status field rather than treating the first response as final.
• We map per-corridor field variation, because a Philippine cash pickup and a Thai bank deposit carry different payout details under one shared transaction shape.
• We wire token refresh into the client so a short-lived session does not drop a long history pull halfway, and we account for the app's release cadence with a re-validation pass when its front end changes.
• We model points as a ledger separate from remittances, since daily accrual and referral credits post on their own schedule and would otherwise pollute transfer reconciliation.

Access is arranged with you during onboarding — the build runs against a consenting account, and we scope each surface to what you actually need.

App screens

Public store screenshots, used to read the app's surfaces. Click to enlarge.

What I checked

I read the app's Play Store listing for its data surfaces, fees and remittance timing; Tranglo's published account of the CROSS ENF partnership for the corridor count and company background; Korea's FSC pages and the Foreign Exchange Transactions Act for how small-sum remittance is supervised; and current PIPA / MyData coverage for the data regime. Reviewed June 2026 by the OpenBanking Studio integration desk.

• CROSS: REMIT & SHOP — Google Play listing
• Tranglo — CROSS ENF growth and corridor partnership
• Financial Services Commission (Korea)
• Korea fintech law — PIPA, Credit Information Act, MyData

Other Korea-corridor remittance apps

Same category, useful when a unified integration spans several providers. Listed for context, not ranked.

• SentBe — Korea-licensed remittance to 50+ countries; transfer and FX records sit behind an account.
• Hanpass — remittance and currency exchange with bank-deposit, cash-pickup and home-delivery payout, each with its own status data.
• WireBarley — remittance operator that has used RippleNet; per-user transfer history and rate data.
• Moin — Korea remittance startup holding transfer records and saved recipient profiles.
• GME Remittance — large Korea provider for migrant workers; transfer ledgers and KYC state.
• E9pay — registered small-sum overseas remittance; corridor transfers and payout tracking.
• Coinone Transfer (GmoneyTrans) — blockchain-settled Korea remittance with per-user transfer history.

Questions integrators ask about CROSS

Does CROSS expose remittance status in real time, or only after settlement?

Both. A transfer is described as completing in about five minutes per its own listing, and the app shows status at the moment of application and again on confirmation. We capture the status field as it changes through the corridor, not just the final settled state, so a synced ledger matches what the sender sees in the app.

Can the points balance and referral ledger be read the same way as transfer history?

Yes. The daily app-open points, the 10,000-point referral credit and the running balance sit behind the same authenticated session as transfer history, so one auth flow reaches all of them. We model points as a separate ledger surface because its entries accrue on a different schedule than remittances.

How does Korea's MyData regime affect a CROSS integration?

MyData gives data subjects a legal route to have financial data transmitted, supervised by the PIPC under PIPA. For a small-sum remittance app the dependable basis we build on is the account holder's own explicit consent; MyData is where formal data portability may extend. We operate under PIPA and the Credit Information Act either way, with consent records and data minimization.

We need both the Thai and Philippine corridor data — does that change the build?

The transaction schema is shared across corridors, but payout fields differ by destination and payout method, and the Philippine corridor is one CROSS grew heavily through Tranglo. We map the per-corridor field variations so a Thai bank deposit and a Philippine cash pickup both normalize to the same record shape on your side.

Working with us

You give us the app name — CROSS: REMIT & SHOP — and what you want out of its data; we handle the route, the access and the code. Two ways the work is priced. Source-code delivery starts at $300: you get the runnable integration, the spec, tests and docs, and you pay after delivery once it works for you. Or run it as a hosted, pay-per-call API with no upfront fee — you call our endpoints and pay only for the calls. Either way the cycle is one to two weeks. Tell us what you need on the contact page and we will scope it.