Start with a business and a purpose
The business describes who is paying, who is receiving, the commercial purpose and the required route. Swyby’s fintech model is designed for business customers. It is not presented here as an anonymous exchange, a consumer wallet or a peer-to-peer remittance service.
Establish the provider relationship
The selected provider and the customer’s required agreements are identified before any regulated service begins. Depending on the approved arrangement, Swyby may have a platform agreement while customers separately accept the provider’s terms and complete individual onboarding. A shared interface never conceals the underlying customer.
Where supported, onboarding can be embedded in the product. Swyby can collect or transmit required information; the provider performs verification and makes the eligibility decision.
Review the actual quote
A production instruction must show the appointed provider, the supported asset and network, relevant fees and any available delivery estimate before confirmation. Provider figures are presented as supplied. Swyby’s agreed software or platform fees must be identified separately.
There is no live quote on this website. An illustrative source amount is not an offer to exchange or settle.
Send funding directly to the provider
- Business customerDefines and confirms a legitimate business payment.
- SwybyCoordinates the request, provider handoff and workflow record.
- Appointed providerReviews the customer and instruction; returns decisions and status.
- Business customerFunds the provider-designated account or wallet directly.
- Regulated providerHandles required checks, conversion and settlement.
- Approved destinationA beneficiary bank account or provider-approved wallet.
For a supported collection route, local funds enter the provider-designated account; the provider performs conversion and transfers supported assets to the approved destination. Swyby is outside that funds path too.
Track decisions, exceptions and outcomes
Created, under review, accepted, processing and settled describe different events. A rejected request is not a pending payment; a provider hold is not a software error; a requested return is not a completed refund.
A refusal ends that provider route. Swyby does not automatically route a refused customer or transaction elsewhere to evade that decision. Any separate application is subject to the other provider’s own checks.
Keep the record and its provenance
Swyby can organize the request, provider references, status history and support context. The provider’s settlement information remains authoritative. A local export is a workflow record, not a bank statement or provider receipt.
Try the illustrative workflow