Key information across the Gravv platform.
Gravv incorporates the right safeguards expected of financial infrastructure operating across multiple markets.
Many teams create separate main accounts per product line, feature, or operational flow. This keeps balances and activity attributable without introducing separate systems or integrations.
Main accounts belong to your business and are used to manage operational funds such as revenue, payouts, card-backed balances, or longer-term holdings. Customer accounts belong to your users and reflect money they send, receive, or hold through your product. Keeping these separate helps maintain clarity around ownership and activity.
No. Each account maintains its own balance. Funds only move between accounts through explicit transfers, which keeps ownership and intent clear.
Teams often use dedicated main accounts for fees or revenue. Incoming funds can be routed or allocated internally so fee-related balances remain distinct from customer or operational funds
Because every balance change is tied to a recorded movement, reconciliation becomes a matter of reviewing activity rather than reconstructing it. This applies to both customer accounts and business accounts.
Yes. While the account model remains consistent, teams can apply region-specific rules or flows around accounts without changing the underlying structure.
Outgoing transfers always reference a specific source account. This keeps it clear where funds originated and ensures balances reflect outgoing activity accurately.
Gravv supports four transfer types: internal transfers between Gravv accounts, external fiat transfers using local banking rails, international transfers to bank and mobile money accounts, and digital transfers between wallet addresses.
External fiat transfers use established banking rails, including ACH, Wire, SEPA, INTERAC, and Faster Payments, depending on the country and currency involved.
No. External recipients (bank accounts or payout destinations) are added once and stored as external accounts. Once added, they can be reused across multiple transfers.
Completion time depends on the transfer type, rail, and destination country. Local transfers typically complete faster than international or regional payouts. Status updates are provided throughout the lifecycle of each transfer
Transfers are reflected in account balances and records as they progress. Final settlement is recorded when the transfer reaches a completed or failed state.
Yes. The system is structured to support issuing and managing large numbers of cards while keeping controls and visibility centralized
Each card is linked to an internal account. All spending draws from that account balance, keeping card spend separate from other funds such as treasury or payouts
Virtual cards are available immediately after creation. Physical cards follow standard fulfillment timelines but are managed through the same interface.
If you’re planning to issue cards for a specific consumer or B2B scenario, sharing details with our sales team allows us to guide you on the most appropriate setup
Some methods can confirm quickly, while others depend on local banking timelines. Gravv provides status tracking so your product does not need to assume timing. Your UI can show “pending” until completion is confirmed.
Gravv supports multiple collection methods, including:
Local bank transfers
Card collections (where supported)
Mobile money collections (where supported)
Availability depends on the payer’s country and the currency being collected.
Yes. Collection methods can be enabled or disabled based on your product logic, customer type, or region
Each collection is routed to a single internal account. If you need to split funds, this is typically handled after settlement through internal transfers.
It’s currency exchange and settlement liquidity used to support collections, transfers, and treasury flows. It is intended for operational money movement, not trading.
Supported currency pairs and corridors are listed in documentation and can be confirmed during onboarding based on your use case.
Liquidity availability depends on the corridor, currency pair, and use case. Supported routes and behaviors are defined during onboarding and documented for clarity.
Contact us if you have any other questions.
Many teams create separate main accounts per product line, feature, or operational flow. This keeps balances and activity attributable without introducing separate systems or integrations.
Main accounts belong to your business and are used to manage operational funds such as revenue, payouts, card-backed balances, or longer-term holdings. Customer accounts belong to your users and reflect money they send, receive, or hold through your product. Keeping these separate helps maintain clarity around ownership and activity.
No. Each account maintains its own balance. Funds only move between accounts through explicit transfers, which keeps ownership and intent clear.
Teams often use dedicated main accounts for fees or revenue. Incoming funds can be routed or allocated internally so fee-related balances remain distinct from customer or operational funds
Because every balance change is tied to a recorded movement, reconciliation becomes a matter of reviewing activity rather than reconstructing it. This applies to both customer accounts and business accounts.
Yes. While the account model remains consistent, teams can apply region-specific rules or flows around accounts without changing the underlying structure.
Outgoing transfers always reference a specific source account. This keeps it clear where funds originated and ensures balances reflect outgoing activity accurately.
Gravv supports four transfer types: internal transfers between Gravv accounts, external fiat transfers using local banking rails, international transfers to bank and mobile money accounts, and digital transfers between wallet addresses.
External fiat transfers use established banking rails, including ACH, Wire, SEPA, INTERAC, and Faster Payments, depending on the country and currency involved.
No. External recipients (bank accounts or payout destinations) are added once and stored as external accounts. Once added, they can be reused across multiple transfers.
Completion time depends on the transfer type, rail, and destination country. Local transfers typically complete faster than international or regional payouts. Status updates are provided throughout the lifecycle of each transfer
Transfers are reflected in account balances and records as they progress. Final settlement is recorded when the transfer reaches a completed or failed state.
Yes. The system is structured to support issuing and managing large numbers of cards while keeping controls and visibility centralized
Each card is linked to an internal account. All spending draws from that account balance, keeping card spend separate from other funds such as treasury or payouts
Virtual cards are available immediately after creation. Physical cards follow standard fulfillment timelines but are managed through the same interface.
If you’re planning to issue cards for a specific consumer or B2B scenario, sharing details with our sales team allows us to guide you on the most appropriate setup
Some methods can confirm quickly, while others depend on local banking timelines. Gravv provides status tracking so your product does not need to assume timing. Your UI can show “pending” until completion is confirmed.
Gravv supports multiple collection methods, including:
Local bank transfers
Card collections (where supported)
Mobile money collections (where supported)
Availability depends on the payer’s country and the currency being collected.
Yes. Collection methods can be enabled or disabled based on your product logic, customer type, or region
Each collection is routed to a single internal account. If you need to split funds, this is typically handled after settlement through internal transfers.
It’s currency exchange and settlement liquidity used to support collections, transfers, and treasury flows. It is intended for operational money movement, not trading.
Supported currency pairs and corridors are listed in documentation and can be confirmed during onboarding based on your use case.
Liquidity availability depends on the corridor, currency pair, and use case. Supported routes and behaviors are defined during onboarding and documented for clarity.
