Bakkt selects Thredd for a stablecoin-settled credit-card proof of concept

Sourced news briefing

Thredd announced on 13 October 2026 that Bakkt selected it for a planned US credit-card-as-a-service programme designed to settle in stablecoins. Thredd describes processor and credit infrastructure responsibilities, with Bakkt supplying settlement rails. An initial proof of concept is targeted for the first half of 2027, subject to readiness, client timing, bank and network requirements, and approvals. This is a future project rather than a live merchant offer. The following analysis separates card acceptance from potential backend settlement changes.

Independent merchant analysis: follow each layer of value movement

A programme of this kind contains several distinct layers: consumer credit authorization, card-network messaging, issuer processing, lending records, merchant acquiring and backend settlement. Stablecoin movement may occur between programme participants without changing the shopper’s card experience. Merchants evaluating a future offer should ask where fiat is converted, who holds the digital asset, which stablecoin and chain are used, when settlement becomes final, and whether the merchant can or must receive a digital asset. A generic statement about stablecoin settlement cannot answer those questions.

Credit risk also remains separate from payment settlement. The issuing bank and programme structure determine underwriting, account management, billing and consumer obligations. Network rules still govern card messaging and merchant disputes. A faster or programmable backend rail does not erase chargebacks, refunds, fraud, sanctions screening or customer-service responsibilities. Each participant needs a reconciled view of the original purchase, issuer ledger, network settlement and any onchain transfer.

Questions for merchants and programme partners

Before relying on a future programme, request a complete funds-flow diagram naming each legal entity, bank, processor, network, custodian, conversion provider and settlement account. Mark when ownership changes and which party bears volatility, operational or counterparty exposure. Confirm how weekends, chain congestion, forks, contract incidents or stablecoin restrictions affect settlement. Determine whether a fiat contingency route exists and how participants recover if the digital-asset leg is delayed after card activity has already posted.

Reconciliation must bridge systems with different identifiers and timing. Merchants need the network transaction reference and ordinary settlement report even if programme participants use a blockchain rail. The programme operator needs a controlled mapping to the onchain transaction. Refunds and reversals require special attention because the original stablecoin amount and later fiat obligation may differ. Accounting policies should define the unit of account, valuation source, fees and treatment of unsettled or failed transfers.

Proof-of-concept discipline

The announced first-half 2027 target creates time for controlled design, not a reason to promise availability. A proof of concept should have narrow participants, limits, clear success criteria and explicit exit conditions. Tests should include normal purchases, reversals, partial and full refunds, disputes, failed settlement, wallet unavailability and a move to contingency rails. Security review should cover signing keys, permissions, smart-contract dependencies and the handoff between processor and settlement systems.

Merchants should assess whether the eventual product changes anything customer-facing or primarily changes programme economics. If checkout is an ordinary card transaction, communicate it as such. Do not use stablecoin language to imply cheaper acceptance, instant merchant funds or freedom from card rules unless the final contract and live operation support those claims. Compare the complete arrangement with conventional settlement across cost, liquidity, risk, reporting and support. Readiness depends on the named bank, network and approval conditions that the announcement says are still outstanding.

A useful proof-of-concept scorecard would distinguish the consumer purchase from every subsequent movement of value. Start with an ordinary card purchase and record authorization, clearing, issuer obligation, settlement instruction and final receipt. Then identify exactly which step uses a stablecoin. That makes the evaluation measurable. Without this separation, a successful blockchain transfer could be mistaken for proof that the whole card programme operates reliably, even if another participant still reconciles its position manually.

For a hypothetical failed settlement, establish who remains obliged to pay whom. If a card purchase has cleared but the digital-asset transfer is delayed, someone may need liquidity to meet an existing obligation. The contracts should identify that party, the escalation time and the permitted contingency action. Participants should not assume that a visible onchain balance is available to satisfy every obligation. Availability depends on ownership, controls and the specific agreements, which this announcement does not disclose.

Reversals deserve a separate scenario. A customer can cancel a purchase before capture, receive a partial refund after delivery or raise a dispute later. Those events need not map to reversing the original blockchain transfer. Programme participants should specify whether they use a new transfer, a ledger adjustment, netting or another contracted mechanism. The merchant's support team needs the ordinary refund status and reference, regardless of how institutions settle behind the scenes.

The proof of concept should also test reconciliation across calendar boundaries. A card event, a blockchain confirmation and a bank conversion may appear on different dates. Finance needs a consistent policy for recognizing receivables, liabilities, fees and exceptions. Compare reports at the transaction level and at the aggregate settlement level. If a transfer settles multiple obligations, preserve the allocation rather than treating the blockchain hash as sufficient accounting evidence by itself.

Another evaluation question concerns access when a key participant is unavailable. Programme operators should identify who can view balances, approve transfers, recover service and communicate with counterparties. An emergency procedure should not rely on an undocumented individual with exclusive access. This is an operational design recommendation; the release does not describe the participants' custody or key-management arrangements. Those details should be evaluated in controlled diligence rather than inferred from the technology label.

For merchants following the project, the next useful announcement would explain the actual operating structure and who can use it. Until then, neither a change to checkout nor a new treasury asset should be assumed. A technically successful pilot would still need commercial terms, operating support and the approvals relevant to its eventual launch.

Independent analysis: evidence to request before implementation

For a merchant that receives only fiat through its acquirer, the evaluation may remain largely a supplier-risk exercise. Ask whether the proposed programme changes the merchant agreement, settlement timing, reporting or recourse. If none changes, there may be no reason to introduce digital-asset handling into the merchant's own systems. If a change is proposed, document it explicitly rather than inferring it from the programme's name.

Programme participants should distinguish a blockchain transaction's technical confirmation from the discharge of a contractual obligation. Both may matter, but they answer different questions. The test plan should specify the evidence needed for each and the treatment of exceptions. This article does not determine legal finality for the proposed arrangement; that requires the actual documents and applicable law.

Keep the commercial scorecard independent of the technology demonstration. Compare total funding needs, reconciliation effort, exception costs and support responsibilities with the baseline arrangement. A pilot can demonstrate that a transfer works while leaving those operating questions unresolved. Reporting both achievements and remaining dependencies gives merchants a more useful picture than a single successful-transfer metric.