• UK Open Banking Notice

    TPPs will need to use the entity details for the new Silicon Valley Bank legal entity from 1 August 2022 


    What is happening 

    Silicon Valley Bank (SVB) UK Branch is switching to a new separate entity within the Open Banking Directory. The change relates to plans for Silicon Valley Bank UK Branch to operate as a wholly owned subsidiary of Silicon Valley Bank, which will involve the transfer of the UK Branch business into a new legal entity, effective from 1 August 2022.  


    We will be deploying the changes during the morning of Saturday 30th July 2022 starting after 2:30 am. After this TPPs wanting to consume Silicon Valley Bank’s AIS, PIS & CBPII APIs will need to use the new entity details. Please note that there maybe some disruption to AIS calls over this weekend as we make system changes, but all services should be operating normally by the morning of Monday 1st August 2022. 


    Entity Info Changes 

    Legacy Entity 


     Silicon Valley Bank 

     OB Org Id 


     End date 

     31st July 2022 


    New Entity 


     Silicon Valley Bank UK Limited 

     OB Org Id 


     Start date 

     1st August 2022 



    TPP Impacts 


    TPPs will NOT need to re-register with the new entity – SVB will transfer all existing TPP registrations to the new entity. TPPs will be able to continue to use their existing client credentials with the new SVB entity.  


    Consents & access tokens 

    Any existing consents and access tokens will also continue to be supported by the new SVB entity to minimise any impact to TPPs and end-users.  


    Endpoint URLs 

    The SVB base path will NOT be changing and there are no changes to our endpoint URLs.  

    The SVB .well-known endpoint URL also will NOT be changing.  

    The jwks URL will be changing to reflect the new SVB entity and will be updated in the .well-known endpoint from 1st August 2022. 



    TPPs will need to use the new entity’s Org Id in the x-fapi-financial-id header. Any calls received that have the legacy Org Id in this field will be rejected. 


    Message Signing 

    Any messages signed by SVB will have the new entity’s Org Id in the http://openbanking.org.uk/iss claim within the signature. 



    The OBWAC and OBSeal certificates associated with the legacy SVB entity will be deactivated on the 1st August 2022 after the switch over. 

    After our deployment MTLS will need to be established using the new SVB entity’s OBWAC certificate and all messages will be signed with the new entity’s OBSeal certificate. 



    The new SVB entity will be available for testing from the beginning of July in the Open Banking sandbox environment. Parallel running of the new and legacy entity will not be supported in Production so it is recommended that all TPPs test with the Sandbox ahead of the changes.  


    Further questions 

    If you have any further questions, please reach out to apisupport@svb.com 

  • What can be done in the sandbox (test environment)?

    Our test environment allows you to initiate a payment, but we do not process the payment end-to-end. With access to our sandbox environment, you’ll be able to create, read, and delete (only Scheduled Wire payments) test Wire payment.

  • What are the event types that are supported for Webhooks for Wires API?

    We support webhooks for Wire payment status. Clients that subscribes to ‘wires.status’ will be updated if there is a change to the payment status. The following statutes are supported: Scheduled (only for Scheduled Payments), Initiated, Processing, and Completed.

  • What are the cut-off times for Wires?

    Clients can submit immediate USD Fedwire and USD SWIFT payments between 2:00 am PST to 2:30 pm PST on a business day.

    Clients can submit Scheduled Wire payment after cut-off, weekends & holiday with a future date.

  • Can I cancel a Scheduled Wire payment?

    You can cancel a Scheduled Wire payment anytime if the status is Scheduled. We do not allow canceling a Scheduled payment if the processing date has become current.

  • How far in the future can I schedule a Wire payment?

    Clients can schedule Wire payments up to 365 days in future. Future date must be a business day. Only USD Fedwire and USD SWIFT Wire are supported for scheduled Wire payments.

  • Can I initiate a FX Wire payment?

    No, we do not currently support the initiation of FX Wire payments.

  • What types of Wire payments can I initiate?

    Wires API allows you to send Domestic USD Fedwire and International USD SWIFT.

  • Can I initiate a Wire from any of my accounts?

    You can initiate a Wire payment only with a US Demand Deposit Account (DDA). These accounts should be registered for API Banking services for Wires.

  • Are both Incoming and Outgoing Wires supported?

    Currently, we support only outgoing Wires via API. You must register with API Banking services for Wires to initiate a Wire Payment.

  • Outgoing Wire Payment Instruction Requirements

    Domestic Wires

    • Complete Beneficiary (recipient) information including name, account number and address.
    • Complete Beneficiary Bank information including name, city, state, country and 9-digit ABA number.

    International Wires

    • Complete Beneficiary (recipient) information including name, account number, and address.
    • Complete Beneficiary Bank information including name, city, state, country, and 8 or 11-digit SWIFT (BIC) Code.

    Identifying account number as required by the receiving country.

  • Wires Processing Dates

    The Processing Date you enter for a Wire payment is the date that SVB will process the Wire and send the funds to the receiving bank. The date must be a valid bank business day.

    Domestic & International Wires: The processing date must be current date for immediate payments. For scheduled payments up to 365 days is allowed.

  • What is a Wire?

    Wire payments allow two parties to transfer funds from one bank to another by providing the recipient, bank receiving account number, and amount transferred. A wire typically refers to Real-time Gross Settlement (RTGS) networks; these aim for the fastest possible settlement, with the highest dollar limits (and for this these networks also come with the highest fees). Because of these points, wires are the vehicle of choice for our customer’s Treasury team to make certain high-dollar operational payments, such as debt payments or investment settlements. SVB APIs work with two specific networks: Fedwire (USD Domestic) and SWIFT (cross border USD).

  • Which fields in the ACH API will be sent to the recipient, and which are useful for reconciliation?

    The image below displays how key fields can be leveraged to pass information in the API request to create an ACH, that will show up in your Online Banking Portal (OLB). Scroll below the image for information on other important fields as well.

    Important fields that will appear in Online Banking and statements pictured in the OLB Statement below:

    • batch_id - A unique ID indicating the batch this transfer was sent with. Can be used to reconcile   with your SVB bank statements. Will be null until the transfer reaches processing status.
    • memo - Optional 15 digit alphanumeric string that be used to pass data to the recipient bank. 

       For person to person WEB credit transactions, this field is required and should contain   the name of the consumer (originator)

    NOTE: the first field in the description pictured below is the ACH Company ID. This is currently auto assigned based on the setup for the bank account. We do not currently have a way to pass this value in the API request.

    Online Banking mapping of ACH fields





















    Other fields that don't show in Online Banking, but that will be passed to the recipient of the ACH transaction:

    • addenda - Addenda entry specified by the originator. Becomes an addenda row in the NACHA file for ccd, ppd and web payment types.
    • company_entry_description - Description of the transaction specified by the originator, applies to the batch header (so every transaction in the batch receives the same value). Typically this is used for higher-level information about a group of transactions, and could be as simple as "PAYROLL" or and ID for the payment run in your upstream payables system.
  • What is ACH?

    ACH is a cost effective, simple way to make payments.  ACH transactions, no matter how they originate (through the API, file based transfer or Online Banking portal), all must conform to standard NACHA rules.  ACH is a batch-based, store-and-forward process.   All ACH transactions are transmitted by SVB to the Fed at set intervals throughout the day.  

    For more information on ACH payments, please visit SVB Learning Central

  • How do I access NACHA documentation?

    ACH Rules Online

    To set yourself up for access to the rules, go to http://www.nachaoperatingrulesonline.org/

    1. Click the Sign Up link under the New Account box at the right side of the login screen
    2. Enter your Email Address, Password, First and Last Names, as well as the Word Verification code.
    3. Click Continue
    4. Click on Claim Another Subscription
    5. Click on “Check this box if you do not have a subscription code” for access to the Rules.
    6. Enter your contact information, and click on Redeem.
    7. Be sure to bookmark the ACH Rules page in your internet browser.
  • What is an ACH credit?

    ACH credits push funds from your account to merchants, vendors or other parties.  Common use cases are payroll, expense reports and vendor payments.  ACH credits can be performed on consumer or commercial accounts and can be same-day or future dated transactions.  You must be set up within the ACH API with appropriate permissions to perform ACH credits.

    For more information on ACH payments, please visit SVB Learning Central

  • What is an ACH debit?

    ACH debit is a method to 'pull' funds from another account.  Common use cases are mortgage payments, HOA dues, gym memberships, ecommerce payments, etc.  You must obtain permission (authorization) from the owner of the account to pull funds from their account.  ACH debits can be performed on consumer or commercial accounts and can be same-day or future dated transactions.  You must be set up within the ACH API with appropriate permissions to perform ACH debits.

    For more information on ACH payments, please visit SVB Learning Central

  • Can I originate both debit and credit ACH transactions?

    Yes, but originating debits requires additional approval.  See your Global Treasury and Product Advisor.

  • What are ACH SEC Codes?

    A Standard Entry Class (SEC) Code is the three character code that identifies the payment type and formatting requirements.   The SEC code is found within the ACH Company/Batch Header record of the ACH File.   The range of SEC Codes that you want to use must be specified in your enrollment agreement with SVB.

    For more information on ACH payments, please visit SVB Learning Central

  • Can we use a non-SVB account as the sender / origination account for an ACH transaction?

    As it relates to SVB's ACH offering, a requirement of the NACHA rules is that SVB must be party to one side of the transaction.  As such, when you generate a transaction, either the account number from which you send funds or the account from which you receive funds must be an SVB account.

  • In an ACH transaction, is there a way to validate that the receiving account number is correct?

    As the originator, it is important that you verify the receiving account information before initiating a transaction.  SVB sends the transactions to the Fed based on the information provided; if the information is not valid, the receiving bank returns the transaction.

  • Are pre-notes available via the ACH API?

    Yes, this is available.  A pre-note is a zero dollar transaction that you send out to a particular recipient to see if you get a return. 

  • What causes an ACH Return?

    Most often transactions are returned due to an incorrect account number, invalid routing number, closed account etc. for the recipient account.  A return can also happen if the recipient does not approve of the transaction.

    For more information on ACH payments, please visit SVB Learning Central

  • Regarding ACHs, what is ‘prefunded’?

    SVB will take the funds from your account prior to sending to the Federal Reserve.

    For more information on ACH payments, please visit SVB Learning Central

  • When will the money be in our bank account from the ACH debit transactions we've initiated?

    1. For non-same-day debit transactions (transactions that pull funds), funds will post to your account the morning of the effective entry date (around 5am PT).  They will also pull the funds from the other Financial Institution on that date.
    2. If the debit transaction is a same-day transaction, funds will post to your account the same day, roughly 5:00p PT.
  • When will the money be debited (pulled) from our bank account from the ACH credit transactions we've initiated?

    1. Generally, credit transactions (that push funds),  will post to your account the day they are sent to the bank – i.e. if you send on Monday, the funds will be pulled out of your account on Monday, and the remitted funds will be posted on the effective date of the transaction at the other institution.  The NACHA rules say they must be available by “opening of business” at the recipient Financial Institution.
    2. If the credit transaction is a same-day transaction, funds will be pulled from your account intraday, prior to sending the file to the other bank, and the funds will be available at 5:00 PM of the recipient bank’s local time.
  • What is Same Day ACH?

    Most ACH transactions are settled on the next business day.  Same-day ACH settles on the same business day.

    For more information on ACH payments, please visit SVB Learning Central

  • What are the rules around Same Day ACH?

    There are 3 parameters that all have to be met to have the transaction settle on a same day basis:

    1.  The service field must be set to 'same-day'.
    2.  The transaction must be received by SVB by 12:00pm PT (it can be sent the previous day if the previous day is a holiday or weekend or after 7:00pm PT of a previous business day)   
    3.  The transaction must be $1,000,000 or less.

    Same-day transactions can be future-dated, but SVB does not recommend this.

  • What are the same day ACH cut-off timings and the time zone in which they operate?

    Transactions sent between 7:00pm PT the night before and up to 12:00pm PT the same business day can qualify for same day posting.  The 'service' field must also be set to 'same-day'.  If the service field is set to 'standard' or blank, even if it is sent within the appropriate same-day hours, it will be sent out as a next day transaction. 

  • Is there a pricing difference for same day ACH payments?

    Yes. Same Day ACH is a premium service that incurs an additional per item charge.  It is available for both debits and credits.

  • What is the ACH API?

    The ACH API is an ACH transaction origination application programming interface.   It simplifies the method of creating the NACHA format required to send the ACH transaction into the network. 

  • Will our ACH transaction requests process immediately?

    Clients can submit ACH transactions requests to SVB 24x7, however, given the limitations of the ACH Network, SVB generates and sends out the NACHA files to the Fed at predefined intervals on business days only.   ACH transactions submitted through the API are still subject to the same NACHA rules and turn-around time as any other ACH transaction submitted through any other channel (SVB Online Banking or via FTP).

  • How long does it take for an ACH transaction to move from “processing” to “succeeded”?

    Three business days if SVB has not received a return.  (Background: The ACH network does not provide positive confirmation of transaction completion.  SVB marks ACH items sent via the API as successful after 3 business days following the processing date based on our knowledge of the network given that the majority of returns come back in the first 3 business days.   Returns can continue to come back after that time, based on the NACHA rules.)

    Example below:

    10/5– Fri Day Zero - you send SVB a request and SVB sends it to the Fed.

    10/6 – 10/7 – Weekend.  No activity.

    10/8– Mon Day One - effective entry date –return clock starts here.

    10/10 – Tues Day Two - by End-of-Day – return typically sent back to SVB

    10/11 – Wed Day Three – SVB marks the item as successful if we haven’t received a return.  

  • My ACH transaction came back as ‘succeeded’ but now it’s showing as ‘failed’ – what happened?

    We mark items as 'Succeeded' 3 business days following the effective date (assuming we have not received a return by that time).  However, per NACHA rules, a contested transaction could return up to 60+ days after the effective date, which would change the status of your transaction from ‘succeeded’ to ‘failed’. 

  • If the effective date of an ACH is left blank what happens?

    If left blank, the ACH effective date defaults to the next business day.  Example: if you send SVB the transaction on Thursday (up until the deadline on 7:00pm PT), we will send out the transaction on Thursday for a Friday effective date. 

  • Can the ACH effective date be back-dated, or future-dated?

    The API will produce an error if you try to back-date the effective date of a transaction.   If you future-date the transaction it will go out to the Fed the business day prior to the effective-date.

  • What times of day does the system update the ACH status?

    ACH status changes occur on the following schedule:

    • Pending' to 'Processing' happens a few times per day (3:10am, 5:40am, 9:10am, 10:30am, 12:10pm, 3:40pm, 5:10pm PT – no weekends or holidays).   
    • Moving from 'Processing' or 'Succeeded' to 'Failed' is based on Returns from the Federal Reserve. That happens up to 4 times per day (6:30am, 1:00pm, 4:30pm, and 10:00pm PT  – no weekends or holidays). 
  • What happens to payments sent to the API on a weekend or holiday - do they get rejected by the API?

    Payments are accepted through the API on a 24x7 basis, but they won’t go out to the Fed until the next business day.  So for example, if you submit a transaction on a Sunday, it will go out on Monday for a Tuesday settlement date (unless you also set the effective date and service field to ‘same-day’ in which case it will settle on Monday).

  • What SEC codes are supported by the ACH API?

    The API supports three SEC codes: PPD, CCD and WEB.  Which SEC codes you use depends on whether the transaction is going to a consumer or a business and how the authorization was obtained.

    • PPD - Predetermined Payment & Deposit entries are contractual electronic payments or deposits to a consumer account.
    • CCD - Cash Concentration or Disbursement entries are contractual electronic payments or deposits to a corporate account.
    • WEB - Web Initiated-Entry. Consumer only - Electronic authorization through the Internet to create an ACH entry. (Use of this SEC Code at SVB requires additional approval and setup.)
  • How do I know if an ACH transaction has been returned?

    The ACH API provides 3 options for seeing return activity:

    1. Use the API Status Webhook to notify you of any returns via the API
    2. Query the return status via the Retrieve ACH API
    3. Review the ACH Returns and Correction notice available via the online banking portal.

    Most returns post within three business days (SVB makes them available as soon as we receive them), but it can be much longer for contested transactions (see NACHA rules).  

  • How often should I check the ACH transaction status for returns?

    We recommend using webhooks for ACH transaction status updates    

    If instead of webhooks, you use the Retrieve ACH API, SVB receives returns from the Federal Reserve at 4 pre-defined times during the day (10:00am, 1:30pm, 5:00pm, and 9:00pm PT).  You only need to check for returns at these 4 times of day.

  • What metadata might we want to include as part of the ACH transaction?

    Metadata is optional; the intended use is to simplify querying for objects via the API that you can then filter on it in your query (for example, your own reference id).  Note that Metadata does not carry on the ACH transaction to the recipient.

  • Is it possible to create counterparties and create transactions referencing those counterparties, rather than including full bank account details with each request?

    This feature is currently in Beta, please refer to Counterparties API page for more information.

  • Do we need to use Network Time Protocol (NTP) on our servers to use the ACH API?

    Yes, your server's clock (adjusting for timezones), needs to be in sync with our server's clock, so that the timestamp submitted with your transaction matches within 30 seconds to the timestamp on our end, otherwise the transaction will fail.   The server clocks will match, as long you use Network Time Protocol (NTP) on your server.

  • What is a virtual card?

    A virtual card, also commonly called a virtual card number (VCN), single use account, or pseudo card number is a digital-only card that can be created on demand through an API connection to a bank.

    SVB's virtual cards are commercial credit cards that can be used by SVB clients to make payments. Each virtual card number can be created in real time, and through the API you can define a set of spending controls, attach reference data, and receive reporting on card usage.

  • How do virtual cards differ from traditional plastic cards?

    Virtual cards are standard 16-digit card numbers and have all of the standard associated information—a cardholder name, billing address, CVC2, and MM/YY expiration date—needed to make a purchase or payment. They can be processed by card-accepting merchants through their existing infrastructure like any other card payments.

    However, no plastic card is ever issued, only the virtual card number, so virtual cards are best suited for online purchases and payments where card information is directly sent to your suppliers or trading partners.

  • What are some common uses of virtual cards for payments?

    Virtual cards are commonly used by companies for their own corporate purchasing and travel needs and as a payment method to pay suppliers for approved invoices, alongside checks and ACH.

    Additionally, virtual cards are being used by companies for new, innovative payments use cases. Essentially, VCNs are programmable credit card numbers. With features such as spend controls, the ability to create one-time-use cards, and real-time authorization and decline reporting, it's possible for SVB clients to create custom, embedded payment flows unique to their business models. We've seen great use cases from ecommerce marketplaces, B2B and C2B bill payment services, on demand services, alternate lending companies, claims payments, online travel booking, and many more!

  • What kinds of spending controls can I set on a virtual card?

    When creating or updating a virtual card, you can define the total spending limit for the card, number of times it can be used, as well as a start date and end date for when it can be used. You can also define a per transaction minimum and maximum. By setting the per transaction maximum and minimum to the same amount, you can restrict the card to only be used for that amount. Controls are also available to restrict to specific Merchant ID's (MIDs) and Merchant Category Codes.

  • Are virtual cards credit cards or prepaid cards?

    SVB's virtual cards are corporate credit cards, not prepaid cards.

    Rather than pre-funding your program and tying up cash before creating virtual cards, a credit limit is established for your card program and you will be able to use VCNs for purchases as long as the outstanding balance on your card program has not reached the credit limit. Your company will then periodically to pay SVB back for the outstanding balance as per the terms of your card program agreement.

  • Do virtual card numbers recycle?

    No, each virtual card number is only issued once to a client, and the card numbers are not pooled or recycled over time.

  • Are there limitations on how many virtual cards my company can create?

    No, there is not a hard limit on the number of virtual cards you can create at any given time, but the usage of virtual cards in transactions will be limited by the available credit on your company's card program.

  • What is an RCN (Real Card Number)?

    The RCN is a "real card number" which acts as a parent account for your virtual card numbers. Each virtual card number that you create has to be assigned to an RCN. This RCN will have a credit line and an outstanding balance that needs to be periodically repaid; repayment happens at the RCN level not the individual VCN level. The RCN itself is not directly used for making card purchases.

  • Can I make international payments with a virtual card?

    Even if the spending controls you set are in USD, you can still use virtual cards to pay international merchants. We recommend adding a buffer to the spending limit when creating a VCN for an international transaction to accommodate exchange rate fluctuations between the time you create the card and when it is used by the merchant. The exchange rate is set by Mastercard, and additional foreign transaction fees may apply as per your card agreement.

  • What virtual card reporting options are available?

    You have several options for viewing your virtual card and VCN transaction details for transactions submitted through the API:

    API: View virtual cards and transaction details (authorizations and clearings)

    Website: View virtual cards and transaction details (authorizations and clearings)

    File: If you need to send transaction details to an expense reporting provider, SVB can send a daily CDF3 file—standard Mastercard file format for card transactions. Please contact your company's Global Treasury Product Advisor if you need to set up a CDF3 file.

  • Regarding virtual cards, what is an authorization?

    When a merchant processes your VCN for a transaction, they route an authorization request through the Mastercard network to SVB. The controls you set on the VCN are checked, as are your company's overall card credit line, fraud screening, etc. and the merchant receives either an authorization approval or a decline response. Merchants are almost always required to obtain an authorization approval based on the Mastercard network rules

    This authorization request step happens when the merchant keys in your virtual card to their virtual terminal or you complete checkout on an ecommerce page. It is similar to what happens with a plastic card when that card is swiped or the chip is inserted at the point of sale in a store.

    Authorizations happen in real-time and reporting on authorization approval and decline events are available through the VCN API and webhook events.

    An authorization is necessary to check whether the card holds sufficient funds and is approved to purchase by a Merchant.  Authorizations are available through the API in near-real time.

  • Regarding virtual cards, what is clearing data? Is this the same as settlement data?

    After a merchant receives an authorization approval, they must perform a second step to complete the card transaction and receive funds. This second step is often performed at the end of the same day or the next day, and sometimes merchants do not complete this step until goods are shipped. This second step is called clearing. Sometimes merchants refer to it as "capturing" a transaction. Clearing causes the funds to move between the issuing bank (SVB) and the merchant's acquiring bank, which is called settlement. Clearing also causes the card transaction to "post" to your RCN's account. Capture, clearing, settlement, and posting are all part of this same process.

    Clearings are processed by Mastercard in batches and clearing data is updated daily through the VCN API and webhook events.

  • Why are transaction amounts sometimes different between authorizations and clearings with virtual cards?

    There may be times when the authorization amount and clearing amount differ for a transaction. The spending controls you set on a virtual card are enforced at the time of authorization, but not clearing.

    The most common scenario is a merchant authorizing for a higher amount based on an estimated total but then clearing for a final amount that is lower. An international transaction may also have different cardholder billing amounts due to the exchange rate changing between the time of authorization and clearing.

    There are a few merchant categories in which the Mastercard rules permit a merchant to submit a clearing amount higher than the authorization amount, usually where tipping or gratuity is involved (e.g. restaurants, hair salons, hotels), but in most scenarios a merchant is required by the card network rules to submit a transaction for clearing at an amount equal to or less than the amount of their authorization approval. If you observe transactions where the clearing amount is unexpectedly higher than the authorization amount, we recommend you contact the merchant directly to investigate, and if necessary contact SVB Card Services for additional research.

  • What is a "forced posting" for virtual cards?

    A forced posting is a common term for transactions where the merchant submitted a clearing event without first receiving the proper authorization approval. If you observe an unexpected clearing record that does not have an associated authorization approval, we recommend contacting the merchant directly to investigate, and if necessary contact SVB Card Services for additional research. If the transaction was not properly authorized, you may be able to dispute the transaction with the merchant

  • Why is my virtual card being declined during the authorization process?

    If the transaction is not allowed based on a control you set on the VCN (i.e. transaction amount, number of uses, validity period), the transaction will be declined and a reason will be populated in the vcn_response field.

    A transaction may also be declined if your overall card program has reached its credit limit or for reasons related to fraud prevention. These program level reasons are populated in the issuer_response field.

    There may also be rare circumstances where the card is declined by the merchant or their acquiring bank and are not sent to Mastercard and SVB for authorization. In these cases, decline information will not appear as SVB will not have visibility into the local merchant decision.

  • What happens when I cancel a virtual card?

    Canceling a VCN will prevent future authorization approvals on the card. Returns will still be processed and any previously approved authorizations will still be allowed to clear based on the Mastercard Rules

    Canceling a VCN also means the VCN information, authorization data, and clearing data will no longer be visible through the VCN API. If you are looking to temporarily disable a card, consider changing the controls on the card rather than cancelling it (e.g. change the total_card_limit to $1 to prevent any transactions above $1)

    Cancelled VCNs cannot be un-cancelled.

  • How do returns / refunds work for virtual cards?

    If a merchant initiates a refund, the available balance on your VCN will increase and the refund will appear on your RCN, reducing the outstanding balance owed to SVB.

    Refunds will continue to work even if the VCN has expired or has been cancelled, the spending controls you set on the card only apply to purchases, not refunds.

    Depending on how the merchant initiates the refund, you will only see the refund in your clearing events as a "credit" and generally will not see an authorization event for the refund. Refunds may take a few days to process before they appear on your accounts.

  • Can I stop a VCN transaction after it has been authorized by the merchant?

    No, not through the Virtual Card API. Even if you cancel the VCN or change the spending controls on the card, that will only impact future authorizations or purchase attempts. Any existing authorizations will be honored per the Mastercard network rules and clearings will be allowed. Please contact the merchant directly if you are looking to stop or reverse a transaction after the merchant has received authorization.

  • What happens if I cancel an order before it the virtual card transaction clears?

    In most cases, if the merchant supports cancelling an online order, and you cancel an order after a merchant has received an authorization approval but before the merchant has submitted the transaction for clearing, the authorization will remain in effect but the merchant will not submit the transaction for clearing. The available_balance on the VCN would remain reduced by the original authorization amount but if the transaction does not clear you will not be billed.

    In some circumstances, the merchant will reverse the authorization approval. If they reverse the authorization approval, the available_balance on the VCN will increase by the reversal amount. However, the authorization reversal will not appear through the API as an authorization event.

  • How do I repay my RCN outstanding card balance?

    Your RCN's outstanding card balance can be viewed through SVB Online Banking or by contacting SVB Card Services. You can schedule a payment through SVB Online Banking, contacting SVB Card Services, setting up an auto-pay schedule, or following the instructions on your paper statement

  • Can I add a virtual card to a mobile wallet (e.g. Apple Pay or Google Pay)?

    No, currently virtual cards cannot be added to mobile wallets. They are commonly used for online purchases or for direct delivery to a supplier or vendor of your company.

  • Can I reuse a virtual card?

    Yes, virtual cards can be used for multiple purchases based on the transactions_max parameter that you set when creating them. You can also update the controls on a virtual card over time.

  • Is there a website that can be used alongside the VCN API?

    Yes, authorized users at your company can log in to SVB's SmartData card portal. This website allows you to view the VCNs that your company has created, view transaction activity, update your virtual card program, and even create VCNs.

    While you can create and update VCNs via this web interface, we recommend doing so primarily through the API. VCNs created on the website are not viewable through the API, and any updates made on the website to VCNs that were created on the API will not be reflected in the API.

  • What are the pre-requisites for production implementation?

    In order to use the VCN API in production, your company will have to be an SVB client, and you will have to establish a virtual card program with your SVB Global Treasury Product advisor, which includes completing an application, legal agreements, and credit underwriting. Once the card program is approved and the RCN is established, SVB will be able to issue production VCN API keys.

  • What are the pre-requisites for trying out the VCN API sandbox (test) environment?

    If you are already an SVB client, we can provide you with a sandbox (test) key once you sign the SVB API License Agreement.  Additional legal documents and forms will need to be completed for production use in order to establish the production card program.

  • What can be done in the sandbox (test environment) for virtual cards?

    Our test environment allows you to check the syntax of your API code, but not to submit any end-to-end transactions. With access to our sandbox environment, you’ll be able to create, read, update, and delete test VCNs.

  • Please note: We are providing 90+ days notice of this breaking change to our base URI path for UK AISP, PISP, CBPII endpoints

    Please note: We are providing 90+ days notice of this breaking change to our base URI path for UK AISP, PISP, CBPII endpoints.

    Start date and time : 18 September 2021 3:00 AM UK time

    End date and time : 18 September 2021 7:00 AM UK time


    We are making this change in order to conform to OB standard nomenclature for all endpoints. Currently, our endpoints do not include the usual 'open-banking' and ‘aisp/pisp/cbpii’ paths:


    Current endpoint:


    Future endpoint:




    Current endpoint:


    Future endpoint:




    Current endpoint:


    Future endpoint:



    TPP developers will need to update their base path for all endpoints.

  • What do I do if I have more questions?

    Detailed information is available from our APIs Tab, or through documentation on our developers support site https://www.svb.com/developers, but if you don’t find what you are looking for, Please contact apibanking@svb.com.

  • What APIs does SVB support?

    SVB APIs use modern technology and release procedures to maintain high availability and system redundancy. SVB API products serve international clients, providing sophisticated digital payment services. 


    Available APIs - US Services:

    • VCN:  Issue and manage virtual credit cards in realtime.
    • ACH Originate cost-effective standard or same day payments using the ACH network.
    • Webhooks Subscribe and receive asynchronous callback notifications from SVB APIs.
    • CounterpartiesSecure and tokenize payment receiver information.


    UK Open Banking:

    • Get a list of accounts (AISP)
    • Initiate payments on our clients’ behalf (PISP)
    • Get balances for a given set of accounts (AISP)
    • Get transaction information for a given account (AISP)
    • Check the remaining credit / availability of funds (CBPII)

    The API provides data for UK Deposit / Payment accounts held with SVB UK. More detailed information is available in the API details available from our APIs Tab.

  • Are SVB’s APIs compliant with Payment Services Directive 2 (PSD2)?

    SVB's PSD2 APIs were built to meet the Regulatory Technical Standards (RTS) for PSD2 issued by the European Banking Authority (EBA). Our APIs are aligned to Open Banking standards and meet current PSD2 requirements.

  • Is it possible to test an API from this Sandbox?

    If you click on the APIs tab you will see more information about what APIs we support, what parameters they might take, what each one returns, what possible return codes or error responses they might generate and what they mean. When looking at the details of an API you will see a table of the operations contained in the API. This will show what method they are (GET, POST, or DELETE) and what query and header parameters are required specific to that API.