Capital One DevExchange Provides An Important Banking API Blueprint

March 6, 2018

When you take a look at the banking API landscape in the United States, there is one clear leader in the game–Capital One. Their DevExchange program is miles ahead of every one of their competitors, giving them a significant head start when it comes to the banking API economy. Their approach to delivering APIs meets all of my minimum requirements for any successful API platform, and even exceeds it, providing what I’d consider to be a leading example blueprint that all banking API providers should be following.

The Capital One DevExchange begins as any API operation should, with a dedicated portal located at developer.[domain]:

After landing on the home page for the Capital One DevExchange you get everything you need to get up and running with the APIs they have:

The Capital One DevExchange provides four main groups of public APIs currently, started with access to account information in the following areas:

  • Retrieve account products - /deposits/account-products (GET)
  • Retrieve account product details - /deposits/account-products/{productId} (GET)
  • Create new account application - /deposits/account-applications (POST)
  • Retrieve out of wallet questions - /deposits/account-applications/{applicationId}/out-of-wallet (GET)
  • Answer out of wallet questions - /deposits/account-applications/{applicationId}/out-of-wallet (PUT)
  • Retrieve account application details - /deposits/account-applications/{applicationId} (GET)

As well as some credit card offers, showcasing the products they have available:

  • Retrieve product listings - /credit-offers/products (GET)
  • Retrieve card products - /credit-offers/products/cards (GET)
  • Retrieve card products - /credit-offers/products/cards (GET)
  • Retrieve card products by type - /credit-offers/products/cards/{cardType} (GET)
  • Retrieve card product details - /credit-offers/products/cards/{cardType}/{productId} (GET)

Which you can actually sign up for and do a pre-qualification via APIs:

  • Create prequalification check - /credit-offers/prequalifications (POST)
  • Create prequalification acknowledgment - /credit-offers/prequalifications/{prequalificationId} (POST)
  • Create applicant key - /credit-offers/applicant-details POST

Get access to Capital One rewards via APIs:

  • Retrieve rewards accounts - /rewards/accounts (GET)
  • Retrieve rewards account details - /rewards/accounts/{rewardsAccountReferenceId} (GET)

And details about merchants involved in transactions:

  • Retrieve merchant data - /merchant-insights/merchants (GET)
  • Refresh merchant details - /merchant-insights/merchants/{merchantId} (GET)

This version of the API is available in a sandbox and production environments:

You can tell Capital One is moving cautiously with their public APIs, but they are definitely further along than other banks. Beyond what is publicly available in their sandbox and production environment they have another exploratory set of APIs coming from a project they call Nessie, Capital One’s Hackathon API that gives you access to a multitude of real public-facing data, such as ATM and bank branch locations, complete with mock customer account data. This set of APIs was used as part of a hackathon put on by the bank, but are worth showcasing as an example of where the bank is headed with their API road map.

By providing a pretty robust stack of API paths for working with accounts:

  • Get all accounts - /accounts (GET)
  • Delete a specific existing account - /accounts/{id} (DELETE)
  • Get account by id - /accounts/{id} (GET)
  • Update a specific existing account - /accounts/{id} (PUT)
  • Get customer that owns the specified account - /accounts/{id}/customer (GET)
  • Get accounts by customer id - /customers/{id}/accounts (GET)
  • Create an account - /customers/{id}/accounts (POST)

As well as bills that are associated with accounts:

  • Get all bills for a specific account - /accounts/{id}/bills (GET)
  • Create a bill - /accounts/{id}/bills (POST)
  • Delete a specific existing bill - /bills/{billId} (DELETE)
  • Get bill by id - /bills/{billId} (GET)
  • Update a specific existing bill - /bills/{billId} (PUT)
  • Get bills by customer id - /customers/{id}/bills (GET)

Then API paths for managing deposits:

  • Get all deposits - /accounts/{id}/deposits (GET)
  • Create a deposit - /accounts/{id}/deposits (POST)
  • Delete a specific existing deposit - /deposits/{id} (DELETE)
  • Get deposit by id - /deposits/{id} (GET)
  • Update a specific existing deposit - /deposits/{id} (PUT)

And for any details on loans:

  • Get all loans - /accounts/{id}/loans (GET)
  • Create a loan - /accounts/{id}/loans (POST)
  • Delete a specific existing loan - /loans/{id} (DELETE)
  • Get loan by id - /loans/{id} (GET)
  • Update a specific existing loan - /loans/{id} (PUT)

Then providing insight into all purchases:

  • Get all purchases - /accounts/{id}/purchases (GET)
  • Create a purchase - /accounts/{id}/purchases (POST)
  • Get all purchases by account and merchant - /merchants/{id}/accounts/{accountId}/purchases (GET)
  • Get all purchases by merchant - /merchants/{id}/purchases (GET)
  • Delete a specific existing purchase - /purchases/{id} (DELETE)
  • Get purchase by id - /purchases/{id} (GET)
  • Update a specific existing purchase - /purchases/{id} (PUT)

As well as bank account transfers:

  • Get all transfers - /accounts/{id}/transfers (GET)
  • Create a transfer - /accounts/{id}/transfers (POST)
  • Delete a specific existing transfer - /transfers/{transferId} (DELETE)
  • Get transfer by id - /transfers/{transferId} (GET)
  • Update a specific existing transfer - /transfers/{transferId} (PUT)

And withdrawals:

  • Get all withdrawals - /accounts/{id}/withdrawals (GET)
  • Create a withdrawal - /accounts/{id}/withdrawals (POST)
  • Delete a specific existing withdrawal - /withdrawals/{id} (DELETE)
  • Get withdrawal by id - /withdrawals/{id} (GET)
  • Update a specific existing withdrawal - /withdrawals/{id} (PUT)

Details about banking customers:

  • Get all customers - /customers (GET)
  • Create a customer - /customers (POST)
  • Get customer by id - /customers/{id} (GET)
  • Update a specific existing customer - /customers/{id} (PUT)

As well as available merchants:

  • Get all merchants - /merchants (GET)
  • Create a merchant - /merchants (POST)
  • Get merchant by id - /merchants/{id} (GET)
  • Update a specific existing merchant - /merchants/{id} (PUT)

Available ATMS:

  • Get all ATMs - /atms (GET)
  • Get ATM by id - /atms/{id} (GET)

And Bank Branches:

  • Get all branches - /branches (GET)
  • Get branch by id - /branches/{id} (GET)

I am not sure what Capital One’s intentions are with introducing these APIs to the main stack of public APIs, but they are still available within a separate Hackathon sandbox environment:

Beyond the sandbox, hackathon, and production APIs available, Capital One provides all the expected support and communication channels that you expect out of an active API program:

As well as not forgetting the required elements present from the legal department, helping set the tone for API engagements:

Where the Capital One API program really begins to impress is with their usage of Github, and providing of open source solutions:

It isn’t easy doing Open Source in a highly regulated industry, and Capital One not only is doing it, they actually share some of the story behind their struggle. The open source projects they have been releasing, and the stories they’ve told about them on the blog tell just as important of a story as each of their APIs do. Further externalizing how the bank delivers technology at the bank, as well as with partners and 3rd party developers.

The Capital One DevExchange is what ALL US banks should be emulating. This isn’t just about publicly available APIs. This is about being able to deliver APIs consistently, in ways that are in sync with your lines of business. The more you can deliver this publicly, tell the story of it, and release open source code that demonstrates the value it brings, the more you will be able to do this internally, across groups, and amongst your partners. The biggest mistake any bank can be making in 2018 is thinking doing APIs is purely about retail banking. It is really about how agile and effective your bank will be leverage web technology internally, and externally within your company.

Read more...

Previous Article
Where Do We Start The API Conversation At Our Large Organization?
Where Do We Start The API Conversation At Our Large Organization?

It can be tough to know where to start with APIs at your large organization. Everyone is already in motion...

Next Article
Explaining API Security To Organizational Leadership
Explaining API Security To Organizational Leadership

I’ve been tasked with helping explain API security to senior leadership, and wanted to work through my ide...