Development Best Practices for a Great API Banking Experience

Before joining the bank, Zac and I spent the last 2.5+ years working with banks around the world to open public APIs. In joining SVB, we wanted to share some best practices for creating a great API banking experience. Take a moment to sign up so we can share more best practices in the future.

Treat building API banking as you would an engineering problem.

  • Use a modern interface—REST over JSON. These are battle-tested technical approaches. Don't doom yourself to technical mediocrity by using SOAP or XML over RPC. Don't reinvent the wheel.
  • Use standard protocols—SSL, OAUTH, TLS. All three are mature, tested, and well supported in the open source community. Especially with concerns about security, going with something homegrown could leave you open to vulnerabilities you didn't anticipate.

Understand what is critical to creating value. Know that writing software, building systems, and shipping features are only part of it.

  • Clean, simple, and intuitive API design. Though it sounds trite, designing a simple API is harder than designing a complex one. The hallmarks are simplicity, clarity, and being intuitive for a developer to understand.
  • Clear, straightforward, documentation. Making it quick and easy for your developers to understand your API is critical. This includes the design of the docs, how they are written, and making sure it guides new developers while empowering senior ones.
  • Having really good support is critical. There are often issues when integrating with an API. Having support to help resolve your issue quickly and effectively is the difference between a magical experience and a terrible one.

One of the biggest challenges is overcoming the communications gap between developers and banks.

  • Your job is to explain complex banking products in ways that engineers intuitively understand. It needs to be as easy for them to use a bank product as any other API provider. That means masking complexity and using language alien to banks.
  • You need to have engineers talk to engineers. That is the only way to build credibility and trust with the developer community. It is also the best way to keep a fast, iterative, development cycle.

Banks have some specific challenges that all banking API programs must grapple with before launch.

  • The concept of identity is much more complex for banks than for other API providers. This is because of regulatory requirements and customer demand for complex entitlements. Understanding this from the beginning is essential.
  • What are nice to haves in other fields are must haves for banks. There are many areas where this is true but rate limiting, fraud detection, and auditability are just three of the specific areas where you need a solution before going to alpha.
Now Let's Get Started

See how SVB makes next happen now for entrepreneurs like you.

Connect with Us