Prior Crypto Payments News reporting alleged that Fortris processed payment flows for offshore betting businesses serving U.S. customers without authorization in the relevant U.S. markets. That allegation raises a permission-level question: which API powers could observe, create, approve or complete those payment flows, and what prevents visibility access from becoming trading or withdrawal authority?
The benchmark is the September 2026 incident that Haruko disclosed to affected clients. CryptoDaily reported a stolen access token and exposure of exchange API details and trading data; CoinDesk attributed the scope of 15 clients and some reported fund losses to Haruko and people familiar with the incident. The reviewed secondary reports do not identify the attacker, fix a final loss amount or establish negligence. They describe read-only API exposure, not a finding that every exposed credential could trade or withdraw. The Fortris test is to document each permission separately rather than assume another platform’s token design.
“API access” is too broad to govern
Fortris offers payment-engine infrastructure and incoming and outgoing payment workflows. Those functions can involve at least six different powers: reading balances or transactions, placing trades, creating payment instructions, changing beneficiary destinations, approving transfers and executing withdrawals. Administrative powers such as creating wallets, users or policies form a seventh category because they can change who controls the first six.
Fortris should provide customers a permission matrix for every human and machine credential. The matrix should show the exact resources, assets, accounts, transaction types, limits and environments available. A role name such as “operator” or “integration” is insufficient if the customer cannot see the underlying actions. Permissions should default to denied and expire when the business purpose ends.
Observation and action need separate identities
Read access can reveal balances, counterparties, open orders and commercial strategy. It therefore needs protection, but it should not share a credential with transaction authority. Reporting tools should use identities that cannot place trades or create payments. Trading services should not automatically gain withdrawal power. Payment creation should remain distinct from approval, and approval should remain distinct from destination administration.
That separation limits both compromise and insider misuse. An attacker who steals a reporting token should encounter a hard authorization boundary, not merely a user-interface restriction. A staff member who adds a destination should not be able to approve the first transfer to it. A service that prepares a batch of player payouts should not independently release the batch.
Every step toward movement needs friction
Fortris’s governance materials make approval design part of its accountability. Movement-capable credentials should face destination allowlists, amount and velocity limits, asset restrictions, time windows and independent approvals. Changes to those controls should trigger a cooling period or enhanced review, especially when a new address is added shortly before a large withdrawal.
Logs must record both requests and authorization decisions. For each movement, customers should be able to reconstruct who or what created the instruction, which policy evaluated it, who approved it, what exceptions were used and which credential sent the final command. Logs should be immutable and exported outside the system that generated them, so a compromise cannot erase the evidence needed for investigation.
Permissions should match the gaming purpose
The offshore-betting allegation concerns whether payment infrastructure supported operators reaching customers in markets where they lacked authorization. Fortris should therefore connect permissions to merchant, brand, region and transaction purpose. A credential intended to pay affiliates should not become a route for player withdrawals. A regional wallet integration should not send funds to destinations approved for another territory without a fresh policy decision.
Customers also need to know which Fortris personnel and service accounts can override geography, risk or compliance restrictions. An override is itself a permission and should have a named owner, narrow duration and retrospective review. Commercial urgency should not transform a temporary exception into standing withdrawal authority.
The Haruko incident exposes the ambiguity hidden inside the phrase “API exposure.” Fortris can resolve that ambiguity in its own architecture by publishing or supplying a complete permission matrix, independent-approval rules, allowlists, limits and audit records for every transition from seeing an asset to moving it.
Fortris should let customers test a representative credential in a controlled environment and verify that denied actions fail at the authorization layer. The test should cover new destinations, higher limits, cross-region access and administrative changes, with results retained as evidence rather than a one-time demonstration.
The decisive question is simple enough to test: if a credential is compromised, can Fortris prove—before examining the attacker’s behavior—which data it can read, which actions it can request, which actions require another identity and which actions it can never perform? Anything less leaves customers guessing about the difference between a confidentiality incident and a direct path to loss.