Skip to content

docs(usd): the dollar reaches Hong Kong and Singapore too - #66

Open
hallstain wants to merge 2 commits into
china-usd-payoutsfrom
feat/hk-sg-usd-payouts
Open

hallstain wants to merge 2 commits into
china-usd-payoutsfrom
feat/hk-sg-usd-payouts

Conversation

@hallstain

Copy link
Copy Markdown
Contributor

Based on china-usd-payouts (PR #64), which is still open — this page does not exist on main yet. Merge #64 first, or merge this into it.

Lightnet activated USD SWIFT to HKG and SGP on our profile on 18 September 2026, so the page is no longer about one country.

  • The mainland contract is unchanged and stays the strict one.
  • The two new rails get their own section: a longer account (6–30) and BIC (8–16), a company name up to 100, an optional bank name, and none of the beneficiary address block, no purpose code and no invoice — there is no domestic alternative outside the mainland, so every payment there is SWIFT.
  • Two things a client must plan for and cannot read out of a field list: these rails carry no payment reference, so a supplier's order number cannot travel with the wire, and correspondent charges on a SWIFT payment are the correspondents' own, so a beneficiary may receive less than was sent.
  • Refusal codes: USD_ACCOUNT_UNCONFIRMED and USD_AMOUNT_OUT_OF_RANGE for the new rails.

Implementation: Unigox/account#637, Unigox/trades#494, Unigox/agent-scripts#321, Unigox/unigox.com PR.

🤖 Generated with Claude Code

hallstain and others added 2 commits September 18, 2026 15:43
Lightnet activated USD SWIFT to HKG and SGP on our profile on 18 September 2026,
so this page is no longer about one country. The mainland contract is unchanged
and stays the strict one; the two new rails get their own section, because what
they ask for is shorter: a longer account and BIC, a company name, and none of
the beneficiary address block — Hong Kong has no postal code — no purpose code,
and no invoice, since there is no domestic alternative outside the mainland and
every payment there is SWIFT.

Two things a client must plan for and cannot read out of a field list: these
rails carry no payment reference, so a supplier's order number cannot travel with
the wire, and correspondent charges on a SWIFT payment are the correspondents'
own, so a beneficiary may receive less than was sent.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review of the implementation against this page found four statements it does not
support.

The mainland's below-minimum refusal is still CHINA_USD_AMOUNT_OUT_OF_RANGE — a
published code clients branch on. Only Hong Kong and Singapore answer with the
neutral one, and the page had quietly reassigned the mainland's.

On those two rails the BIC alone routes the payment; bank_name is optional and is
not sent to the provider at all, so promising it a routing role was wrong.

"Two to three days" for a bank without a direct SWIFT connection is the
provider's line about the mainland rail, not about these; what they said here is
two working days, longer without a direct connection.

And the session lists one USD row per destination now, not a single one naming
usd-wire-china.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant