INDEPENDENT · SUPPORT PLAN·Technical Support Engineer
Paxos moves regulated money. Support is where the seams show first.
A read on where Paxos sits among stablecoin issuers and brokerage rails, six reproducible defects I found in Paxos's own public API this week, a ticket taxonomy for the APAC desk, and each duty in the posting mapped to a plan. Paired with a working console that runs on Paxos's live market data.
Summary
Paxos issues regulated stablecoins and runs the brokerage rail behind PayPal, Venmo, Interactive Brokers and Mercado Libre. The posting asks for someone to build the support function rather than staff a queue: design the process, automate the repetitive part, investigate trade discrepancies with Brokerage Operations, and get ahead of issues before clients feel them.
So this page does the job rather than describing it. I read Paxos's public market data API for an afternoon and found six reproducible defects, including one where the same endpoint returns a different type for two Singapore markets and breaks any typed client outright. Each is written the way I would file it: assertion, live response, client impact, proposed fix. The console runs those checks against production on demand.
The rest is the operating plan: a ticket taxonomy for the APAC desk, what to automate first, how a fill dispute gets closed, and a first 90 days.
- Technical Support Engineer at BOB, a Bitcoin L2: owned the full ticket lifecycle and wrote the knowledge base that cut repeat queries.
- 5+ years client-facing in crypto-fintech: Customer Success at Aztec, support and community ops at FrodoBots, partner BD at deBridge.
- Builds and reads the stack: wagmi / viem, Solidity, on-chain SQL published as a Dune Wizard.
- Native English and Mandarin, UTC+8, the same working hours as Singapore.
- Found the six defects in section 03 unprompted, before an interview.
Paxos, in context
Paxos runs a licence stack, not a single charter. That is the whole product: a partner integrates once and inherits regulated issuance, custody and settlement in three jurisdictions. For support it means the entity behind a ticket determines what you are allowed to say, and what a wrong answer costs.
USDG is issued by Paxos Digital Singapore Pte. Ltd. under a MAS Major Payment Institution licence, with DBS as reserve banking partner and monthly attestations. PYUSD and PAXG sit under the New York trust.
The rail behind PayPal, Venmo, Interactive Brokers, Mercado Libre and Nubank. Orders, held-rate quotes, market data and asset transfer, over OAuth2 client credentials. This is the surface the posting's trade-investigation duties sit on.
Partners keep up to 100% of the reserve yield on USDG they hold or move. Members include Kraken, Robinhood, Galaxy, Anchorage, Bullish, Gemini, KuCoin, Nuvei, Wirex and Archax. It buys distribution with economics rather than marketing.
The entity map, and why it matters to a support engineer
| Entity | Regulator | What it does | Support consequence |
|---|---|---|---|
| Paxos Trust Company, LLC | NYDFS limited-purpose trust | US custody, PYUSD, USDP, PAXG issuance | US-hours escalation path, NYDFS record-keeping |
| Paxos Digital Singapore Pte. Ltd. | MAS Major Payment Institution | Issues USDG. Reserves banked at DBS | Mint and redeem tickets are regulated payment activity, and they run on a Singapore bank calendar |
| Paxos Global Pte. Ltd. | MAS, DPT services (licensed Nov 2022) | Digital payment token services | Second Singapore entity, different permissions. Know which one a client contracted with |
| Paxos Issuance Europe Oy | Finland FIN-FSA, e-money institution | EU and MiCA market access. Acquired as Membrane Finance, completed Feb 2025 | EU-hours coverage and a different disclosure regime |
| Paxos Labs | Not a licensed entity | Onchain primitives. Acquired Molecular Labs (LHYPE, WHLP) Sep 2025 | DeFi-native surface with a different risk profile from the regulated stack |
Entity list and regulators from Paxos newsroom releases and the Paxos Securities Settlement Company Form CA-1 exhibit filed with the SEC. Detailed in §10.
USDG is issued out of the Singapore entity, banked at DBS, on a Singapore calendar. Crypto settles continuously and DBS does not. Every "where is my redemption" ticket lands on that boundary: a 24/7 chain on one side, a bank with cutoffs, weekends and Singapore public holidays on the other. It is the most predictable ticket category the APAC desk will have, and the most automatable.
The competitive map
Paxos competes in two markets at once, and almost nobody competes in both. Issuance-as-a-service is crowded and getting cheaper. Brokerage rails for regulated fintechs is a narrower field with higher switching costs. The overlap is the moat, and it is also what makes support hard: a single client can be an issuance partner, a brokerage client and a GDN economics counterparty simultaneously.
Stablecoin issuance and infrastructure
| Player | What they sell | Their gap vs Paxos | Where it bites |
|---|---|---|---|
| Circle (USDC) | The dominant dollar token, Circle Mint, CCTP | Sells its own brand. A partner distributing USDC builds Circle's franchise, not their own, and keeps little of the reserve yield | Paxos wins on white-label and on economics |
| Tether (USDT) | The deepest liquidity in crypto | Offshore disclosure, no white-label programme, limited appetite for regulated enterprise integration | Paxos wins on regulated distribution, loses on raw liquidity |
| Bridge (Stripe) | Issuance and orchestration APIs, developer-first | No MAS MPI, no NYDFS trust, no brokerage. Stripe ownership makes some payment partners a competitor's customer | Closest on API quality, behind on charters |
| Agora (AUSD) | White-label stablecoins, third-party reserve managers | Thinner regulatory surface, no Singapore MPI, no brokerage or custody | Direct rival on white-label economics |
| M^0 | Stablecoin issuance as a crypto-native primitive | No bank charters, no regulated custody, no fiat rails of its own | Different buyer, crypto-native rather than enterprise |
| Anchorage Digital | Federally chartered crypto bank, issues USDtb | Bank-first, no brokerage API at Paxos's scale. Also a GDN member | Partner and rival at the same time |
Brokerage and crypto-as-a-service rails
| Player | What they sell | Their gap vs Paxos | Where it bites |
|---|---|---|---|
| Zero Hash | Settlement, liquidity and custody API for fintechs | Not a stablecoin issuer. No MAS-licensed issuance, no attested reserve product to cross-sell | The closest brokerage rival |
| Fireblocks | Custody, transfer and treasury infrastructure | Infrastructure vendor rather than a regulated counterparty. The client still needs a broker | Adjacent, often sits alongside Paxos |
| BitGo | Qualified custody, prime brokerage, trading | Custody-led. Stablecoin issuance is a service line rather than a distribution network | Overlaps on institutional custody and trading |
| Coinbase Prime / CaaS | Institutional trading and embedded crypto | Competes with its own clients for end users, and its brand on a partner's product is a strategic cost | Paxos wins on white-label neutrality |
Positioning read from public product pages, newsroom releases and the Global Dollar Network membership list. Named client targets stay in my application materials rather than on this page.
Where the product is genuinely differentiated (charters, attestation, revenue share), support is a trust function: a careless answer from a licensed entity is a compliance event. Where the product is at parity (API ergonomics, docs, response time), support is the differentiator. Bridge is measurably ahead on developer experience. That is the gap the six findings in the next section are aimed at, because API friction is the one competitive axis a support engineer can move directly.
Why an APAC desk, and what lands on it
The seat is not a copy of the New York desk shifted eight hours. Three things are structurally APAC, and they are the reason the posting exists.
USDG is issued by the Singapore entity and its reserves are banked at DBS. Mint and redeem questions are local-hours questions, against a local bank calendar, under MAS supervision.
A large share of the Global Dollar Network runs Asia-hours desks: Bullish and OSL in Hong Kong, KuCoin, and the regional arms of Kraken, Galaxy and Gemini. When their mint stalls at 03:00 UTC, someone awake needs to answer.
Crypto trades through the US night. A brokerage client's fill dispute at 04:00 UTC is either answered in Asia hours or waits twelve hours, and a twelve-hour wait on a trade dispute is itself the complaint.
Continuous settlement on one side, banking hours on the other. A client submits a redemption on Saturday; the fiat leg moves Monday, later if Monday is a Singapore public holiday. Today that is a ticket. It should be a published cutoff calendar, an expected-value date returned at request time, and an alert when a redemption is still pending past its expected window. Same information, delivered before the client has to ask for it. That is the "proactive support" line in the posting, made concrete.
What I found in the API
I wrote nine assertions a client's integration depends on whether or not the docs promise them, and ran them against api.paxos.com/v2. Three hold. Six do not. Nothing here needed credentials or special access, which is the point: a client's first bad experience is reachable from a laptop, so it should be reachable from a test suite.
| Assertion | What actually happens | What it does to a client | Fix | |
|---|---|---|---|---|
| FAIL | Every market flagged AVAILABLE by GET /markets returns a ticker |
21 of 30 AVAILABLE markets return 400 market X not supported on /ticker. They are routed off the central book |
An integrator who builds its instrument list from market_status logs a 400 per market per poll. It reads as an outage and arrives as a ticket. The markets are fine; nothing says so |
Add has_order_book or venue: CLOB | ROUTED to /markets |
| FAIL | ticker.market is a string equal to the market requested, on every market |
BTCSGD returns "market": 5 and ETHSGD returns "market": 2. The EUR pairs correctly return strings |
The sharpest one. A Go or Java struct, an OpenAPI-generated model or a zod schema fails to unmarshal the entire response. A hard parse error, not a missing value. And because only the SGD pairs are affected, it survives every test that does not happen to touch an SGD market | Serialise the enum by name, then put an SGD market in the contract-test matrix |
| FAIL | A 200 from /order-book always carries bids and asks arrays |
BTCSGD returns 200 with the single key market. No bids, no asks |
resp.bids.length throws a TypeError. The client shows a crash where it should show "no liquidity" |
Serialise empty collections as [] instead of omitting the key |
| FAIL | A 200 from /recent-executions always carries an items array |
BTCSGD returns 200 with body {} |
Same failure one endpoint over. Any client reconciling fills against the public tape breaks on the quiet markets first, which are exactly the ones nobody tested | Return { "items": [] } |
| FAIL | Every 4xx carries a human-readable detail |
A routed market explains itself. A typo'd market returns a bare 400 Bad Request with no detail field at all. Both are 400 rather than 404 |
The single most common integration mistake there is produces a log line with nothing in it. Support cannot tell a wrong market name from a bad credential from a malformed request. One triage round-trip, every time | Populate detail, and add a stable code so clients branch on the code rather than the prose |
| FAIL | A market flagged AVAILABLE quotes a spread a client could trade against |
PAXGUSD quotes roughly 565 bps wide, with effectively nothing resting within 50 bps of mid |
PAX Gold is a Paxos-issued asset flagged tradable on both sides. A partner routing a client market order into that book produces a fill the client disputes, and the dispute lands on support | Pair market_status with an indicative spread or a max-slippage guard, so AVAILABLE carries a quality signal |
| PASS | Prices and amounts are decimal strings, not JSON numbers | Strings throughout | Correct, and worth saying. JSON numbers are IEEE-754 doubles, so a naive parse silently loses precision on satoshi-level amounts. This removes a whole class of reconciliation break | None. Add a per-asset precision field to /markets alongside tick_rate |
| PASS | The book is sorted correctly and never crossed on a liquid market | Bids descending, asks ascending, best bid below best ask | A client can walk the ladder as given for a slippage estimate without re-sorting or filtering crossed levels | None needed |
| PASS | Every symbol is base_asset + quote_asset |
Holds across all 34 listed markets | Load-bearing. Every client's symbol parser assumes it whether or not the docs guarantee it | None. Worth documenting as a guarantee so a future listing does not break it |
All nine run live in the console under "API contract checks", with the real response body attached to each. Probed 30 July 2026. Run them yourself ↗
Four of the six failures are the same bug wearing different clothes: the quiet markets are untested. SGD and EUR pairs, routed markets, empty books. Everything that carries volume behaves correctly. That is what you would expect from a test suite built against BTCUSD, and it is fixable in one pass by adding a dark market and a routed market to the matrix. Not nine separate tickets, one.
Not as six bugs. As one ticket with a runnable suite attached and a severity argument: the type bug ships first because it breaks typed clients silently and a Singapore-market integration is exactly what a new APAC partner tests first. The rest ride along behind it. Support earns engineering's attention by arriving with the reproduction and the priority already argued, not by forwarding a complaint.
The venue, measured
The console sweeps every listed market on load: 34 tickers and every retrievable order book, 44 upstream calls behind one request. Classifying them is the difference between watching a venue and watching a status page. Figures below are from the sweep on 30 July 2026 and move with the market.
| Class | Count | Rule | Example | What support does about it |
|---|---|---|---|---|
| healthy | 5 | Spread ≤ 20 bps, 24h notional ≥ $5k | BTCUSD, ETHUSD | Nothing. These are the markets where a fill dispute is almost always a timestamp or a size question, and the tape closes it in a minute |
| thin | 3 | Spread ≤ 200 bps | LINKUSD, UNIUSD | Size before routing. A pre-trade slippage number given to the client beats a post-trade explanation |
| degraded | 1 | Spread > 200 bps, or under $1k resting within 50 bps of mid | PAXGUSD | Flag it. A market order here produces a disputed fill. This is a proactive alert, not a ticket to wait for |
| dark | 4 | Ticker returns 200 with every price at zero | BTCSGD, ETHSGD, BTCEUR, ETHEUR | Listed, quoted by nobody, and the source of three of the six API findings. Also the two SGD pairs are the ones with the type bug |
| routed | 21 | No central order book, /ticker returns 400 | ONDOUSD, DOGEUSD, PEPEUSD | Document them as routed so a client stops treating a 400 as an incident. One doc page removes a recurring ticket class |
The classification rule lives in one function in the Worker, so the board and any ticket it generates read from the same definition. See it live ↗
A list of 34 markets tells you nothing at 04:00. Five buckets with an action attached to each is a shift handover. The value sits in the written definition of "degraded", which lets two engineers on two continents reach the same verdict on the same market without a call.
Each duty in the posting, my plan
| The posting says | What I would actually do | Evidence I can do it | Shown in |
|---|---|---|---|
| Define and evolve support: design operations that anticipate customer needs | Start from a written ticket taxonomy, not a tool choice. Eight categories, each with what to gather, who owns it, and where authority ends. Then instrument: category volume, true-resolution rate, escalation rate, and repeat-contact rate per client. Tool decisions come after there is something to measure | Built BOB's knowledge base and support process from nothing; AI-QA scorecards and Python eval harnesses at KIP | §06 |
| Client onboarding collaboration with Solutions Engineers for enterprise clients | Own the technical-readiness checklist and the sandbox-to-production gate. Sit in the integration calls and write the client-specific runbook while onboarding, because that is the only time the context is fresh. The routed-vs-CLOB distinction goes in the checklist so a new partner never files that ticket | Partner integrations at deBridge (identify, pitch, integrate); Aztec onboarding for thousands of users | §03, §08 |
| Proactive support: monitor platform activity, spot pain points before they impact clients | The venue sweep, on a schedule, alerting on class transitions rather than absolute thresholds. A market moving healthy to degraded is the signal; the number itself is noise. Same pattern for redemption ageing past its expected value date | Built and shipped exactly this. It runs now | §04, §09 |
| Process automation: find manual repetitive workflows and automate them | Rank by volume times handling time, then automate the top of the list. My first three: the contract-test suite in CI, the fill-check tool as tier-1 self-serve, and a generated market catalogue so nobody hand-maintains an instrument list again | Runs a live data-API product; Zapier, n8n, GitHub Actions, Python; a bilingual RAG support bot in production | §07 |
| Brokerage support: investigate trade discrepancies, monitor execution quality | A fixed method rather than an ad-hoc look. Reconcile the reported fill against the tape and the resting book, sign every deviation adverse-to-client so the number means the same thing on every shift, then either close it with evidence or escalate with the specific fields Brokerage Ops needs. Never send an interim guess | The console does this now on live data, including the drafted client reply and the escalation note | §09 |
| Strategic partnership: technical expert and advocate for named institutions | Per-client runbooks and a quarterly technical review: their error-rate trend, their top three ticket causes, what we fixed, what is still open. Turn support data into something an account owner can take into a client conversation | Enterprise and partner-facing work at deBridge and KIP; ran a B2B pilot funnel end to end | §06 |
| Continuous innovation: document breakthroughs, lead post-incident reviews | Every resolved escalation either becomes a doc change, a test, or an alert. If it becomes none of those it will happen again. Post-incident reviews land on one question: what would have caught this before the client did | Documentation that measurably cut repeat queries at BOB; the nine assertions in §03 are that instinct applied to Paxos | §03, §07 |
The posting also asks for cloud, API and fintech-compliance familiarity, incident management, and comfort with limited process. CompTIA Security+, five years on the client-to-engineering seam in crypto-fintech, and every role above was pre-process.
The support model
"Build support from the ground up" starts with naming what arrives. Eight categories, drawn from what Paxos actually operates. Each one gets a definition, a gather-list, and a clear line on where support's authority stops.
| Category | What it actually is | Gather before escalating | Authority |
|---|---|---|---|
| Mint or redeem not landed | Fiat leg stuck: bank cutoff, missing reference, recalled wire, holiday calendar | Request ID, entity, submitted time in UTC, expected value date, bank reference | Support closes calendar and cutoff cases; Treasury owns anything touching the reserve account |
| Fill or execution dispute | Client believes the price was wrong | Order ID, side, size, reported price, timestamp in UTC, tape and book at that time | Support closes when the tape confirms it; Brokerage Ops owns the order-level record |
| Transfer not arrived | Wrong chain, blocklisted or frozen address, insufficient confirmations, wrong memo | Tx hash, chain, asset, from and to, block confirmations, contract state | Support reads chain state directly; Compliance owns any freeze or blocklist decision |
| API integration error | OAuth, 4xx, schema mismatch, rate limit | Full request and response, credential scope, timestamp, client library and version | Support resolves; recurring causes become a doc change or a test |
| FIX session failure | Sequence gap, logon reject, heartbeat loss, resend handling | Session log both sides, SenderCompID, seq numbers at failure, config diff | Support triages; Connectivity owns the session |
| Market unavailable | Often not a fault: a routed market, or a genuinely dark one | Market, endpoint, response body, what the client expected | Support closes with documentation. The fix is the doc, not the ticket |
| Reconciliation break | Client ledger against Paxos ledger: fees, sub-accounts, partial fills, timing | Period, account, both ledgers, fee schedule applied | Support isolates the break; Finance owns the adjustment |
| Compliance-adjacent | Freeze requests, sanctions hits, Travel Rule queries | Route immediately with the facts and nothing else | Support never decides. Acknowledge, route, say nothing that could be read as a determination |
- True resolution, not first-response time. A fast holding reply that leads to a five-day thread is worse than a slower correct one.
- Repeat contact per client per category. The number that finds a doc gap or a product defect.
- Escalation rate with a reason code. Rising escalation is fine if it is new surface; not fine if it is the same cause.
- Preempted-versus-reported ratio. The only metric that tells you whether proactive monitoring is doing anything.
- A support reply is a statement by a regulated entity. No speculation about cause, ever.
- State what was checked, what it showed, what happens next, and when. In that order.
- Never promise a rebook, a credit or a timeline that belongs to another team.
- Timestamps in UTC, always. A meaningful share of disputes are timezone artefacts and ruling that out first is free.
High-impact moves
Ranked by tickets removed per week of effort. Each one is grounded in something on this page rather than in general practice.
| Move | What it is | Why it pays | Grounded in |
|---|---|---|---|
| Contract-test suite in CI | The nine assertions from §03, run on every deploy, with a dark market and a routed market in the matrix | Catches the SGD type bug before a client does. Four of six findings are the same untested-market pattern, so one fix closes them together | §03 |
| Market catalogue, generated | A doc page built from /markets plus a live book probe, marking each market CLOB or routed | Removes the largest single recurring ticket class: 21 markets that answer 400 by design | §03, §04 |
| Fill-check as tier-1 self-serve | The console's fill investigation, internal-facing, with the order-level record wired in | Turns a multi-hour escalation into a two-minute answer with evidence attached, and standardises the adverse-to-client sign convention across shifts | §09 |
| Venue-health alerting | The sweep on a schedule, alerting on class transitions, not thresholds | Degradation gets flagged to the client before their order routes into it. Converts disputes into pre-trade warnings | §04 |
| Redemption cutoff calendar | Published cutoffs, an expected value date returned at request time, and an alert when a redemption ages past it | Removes the structural ticket category created by a 24/7 chain settling into a bank-hours account | §01, §★ |
| Per-client technical review | Quarterly: their error trend, top three causes, what was fixed, what is open | Makes support data useful to the account owner and surfaces integration debt while it is still cheap | §06 |
First 90 days
Read six months of tickets and classify them against the taxonomy in §06, then correct the taxonomy where reality disagrees. Sit in on Brokerage Ops investigations without touching them. Learn which entity every named client contracted with, and where compliance authority begins. Get FIX session basics to competence, since the posting implies brokerage clients and never says the word. Ship the market catalogue in month one because it is small, it is unambiguous, and it removes a real ticket class.
Land the contract-test suite with engineering, type bug first. Turn the fill-check into an internal tool with the order-level record wired in, and agree the sign convention with Brokerage Ops so a number means one thing on every shift. Write the first three per-client runbooks, starting with whichever APAC partner generates the most tickets. Publish escalation packets per category so nothing arrives at engineering half-specified.
Venue-health alerting on class transitions. Redemption ageing alerts against the cutoff calendar. First quarterly technical review with a named client. By day 90 the number I want to move is the preempted-versus-reported ratio, because that is the one that says the desk is anticipating rather than absorbing.
Read access to the warehouse or a read replica. Without it, trade investigation is ticket-forwarding with extra steps, and every number in §03 and §04 stays limited to what a public endpoint will tell me. A clear compliance escalation path on day one, so I never have to guess at a freeze request. And a straight answer on the on-call rotation, because an APAC support hire covers the hours New York is asleep and it is better to price that in at the start.
The live console
Four things a support engineer does, working, on Paxos's live public data. Read-only, unauthenticated, no credentials anywhere. A Cloudflare Worker fronts the API calls because api.paxos.com sends no CORS header and the venue sweep needs forty-four of them behind one request.
Enter a client's reported fill. It pulls the tape, the book and the ticker, reconciles the price against what actually traded, walks the book for that size, signs every deviation adverse-to-client, and returns a verdict with a drafted client reply and an internal escalation note. Where the public record cannot settle it, it says so and drafts the escalation instead of guessing.
Open ↗Give it a market, a side and a notional. It walks the resting book and returns the fill VWAP, slippage against mid in bps and cash, levels consumed, share of visible depth, and a warning when the book simply cannot fill the order. The question a brokerage client asks before they complain.
Open ↗Every listed market classified healthy, thin, degraded, dark or routed, with spread, resting depth within 50 bps of mid, 24h notional and book levels. The rule lives in one function so the board and any ticket it generates agree.
Open ↗The nine assertions from §03, run against production on demand, each with the live response body, the client impact and a proposed fix. Three pass. Six do not.
Open ↗This reads public market data only. It has no access to order records, client accounts or the reserve account, so a fill check reconciles against the sampled public tape rather than the order-level truth. It is built to show method and judgement on real data, and it is mine, built for this application. It is not Paxos code and it is not affiliated with Paxos. A pre-filled investigation is linkable, so an exact reproduction can be pasted into a ticket instead of described.
Method & sources
Method
- Read the posting (public job posting, 2026), then worked out what the job is from what the group actually operates rather than from the title.
- Probed
api.paxos.com/v2directly across all 34 listed markets:/markets,/ticker,/order-book,/recent-executions. Every finding in §03 and every figure in §04 came from those calls, on 30 July 2026, and each is reproducible with curl. - Traced the entity and licence structure through Paxos newsroom releases and an SEC exhibit, because the entity behind a ticket changes what support is allowed to say.
- Built the console to run the checks live, so nothing here has to be taken on trust.
- Figures move with the market. Where a number is quoted it is stamped with the sweep date.
Sources
- docs.paxos.com: API reference, Crypto Brokerage, REST / FIX / WebSocket, OAuth2 client credentials.
api.paxos.com/v2: live public market data. Probed directly; the console re-runs it.- Paxos newsroom: MAS in-principle approval for Paxos Digital Singapore, Nov 2023; MAS DPT licence for Paxos Global, Nov 2022; Membrane Finance acquisition completed Feb 2025; Global Dollar Network launch and members.
- USDG transparency: monthly reserve attestations.
- SEC, Paxos Securities Settlement Company Form CA-1 exhibit: entity list, domiciles and per-entity employee counts.
- Competitor positioning from public product pages and newsroom releases for Circle, Tether, Bridge, Agora, M^0, Anchorage, Zero Hash, Fireblocks, BitGo and Coinbase.
- Global Dollar Network membership and the DBS reserve-banking arrangement from Paxos releases and contemporaneous fintech press.
Independent work by Edward Tay for the Paxos Technical Support Engineer application. Not affiliated with Paxos. The console is my own build against public endpoints, not Paxos code. edwardtay.com · live console ↗