FAQs

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 

New Entity 

TPP Impacts 

Registration 

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. 

Headers 

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. 

Certificates 

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. 

Sandbox 

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 

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.

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.

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.

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.

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.

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

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

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.

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

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.

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.

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).

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.

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.

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

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.

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

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

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

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

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.

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.

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. 

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

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

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.

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.

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

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.

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. 

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

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. 

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).

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.  

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 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. 

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.

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). 

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).

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.)

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).  

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.

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.

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

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.

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.

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.

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!

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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:

AISP:-

Current endpoint:

*/v3.1/api/*account-access-consents

Future endpoint:

*/open-banking/v3.1/aisp/*account-access-consents

CBPII:-

Current endpoint:

*/v3.1/api/*funds-confirmation-consents

Future endpoint:

*/open-banking/v3.1/cbpii/*funds-confirmation-consents

PISP:-

Current endpoint:

*/v3.1/api/*domestic-payment-consents

Future endpoint:

*/open-banking/v3.1/pisp/*domestic-payment-consents

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

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.

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.

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.