Trust is the Most Important Component of Your Developer Platform

Why Co-Creation Can’t Happen Without Trust

As real-time, immersive digital experiences become the consumer expectation, companies must meet their needs by cultivating a more open and collaborative approach to business. We no longer live in a day and age where one single company or individual can build the ultimate experience. Instead of building monolithic experiences, we are using technology products and services as building blocks to co-develop more meaningful digital experiences for our users.

Whether you’re using a ride sharing app to connect with drivers or shopping your favorite ecommerce site on your phone, it’s increasingly likely that a platform company built that experience, and that additional platform companies are powering it behind the scenes.

A company like Airbnb has built a marketplace to connect potential short-term renters with property owners in a frictionless vacation rental experience. A lot of “building blocks” went into developing their platform, allowing them to build the best experience for prospective renters and owners instead of re-inventing the wheel on things like payment processing. By plugging into existing payment processing systems — for example PayPal, Google, and Stripe — they were able to remove payment friction and focus their energy on the consumer experience of their platform. This approach to building with APIs and industry partnerships typifies the platform mindset.

By decoupling technology from distribution and allowing for the co-creation of experiences, platform companies have a distinct competitive edge. They can meet customers wherever they are — on their mobile phones, on the web, on their voice assistant. But how does trust play into this equation? Especially in industries where trust is foundational to the business?

Breaking Down the Meaning of Trust

Trust is paramount to the financial services industry due to the level of personal information our customers share with us. A similar centering of trust can be found in industries such as healthcare, but it’s importance applies well beyond these two examples.

I take a multi-faceted approach to thinking about and building trust. The starting point for it is really transparency. For an API platform or an open source project, transparency doesn’t start with sharing your product roadmap. It starts with the ability to have genuine conversations and build grassroots credibility with your community. When we started the Capital One DevExchange in March of 2016, we wanted everyone to understand that our platform was built around the concept of “exchange” in every sense — the exchange of ideas, information, and code in a two-way conversation between us and our partners.

We wanted to understand and empathize with the needs of our potential partners and their customers, so we dug into a lot of conversations and asked questions. Everything from “What are they building?” to “What user experiences do they want us to solve for?” to “What spaces are they already in?” to “What assets do they need in those spaces?” I often think of this in terms of “crawl before you walk before you run”. When you communicate openly with a community, you build trust, which allows for empathy and understanding to grow. That openness and transparency is the main force that allows for a positive feedback loop with the community.

Customer Trust

For example, the practice of sharing user credentials with another site that can scrape them and store them doesn’t align with our values. That’s why we’ve externalized our Customer Transactions API and are working to sign aggregators up for this service. This security-minded API will give partners the ability to provide customers with secure access to their Capital One information from within their applications. Using oAuth to enhance data sharing security, it removes the need for giving third parties customer bank login credentials and puts customers in the control seat to decide what data to share and with whom. After all, the trust our customers place in us should not be breached, even when they’re not with us. It should be extended to other places they’re going, and other digital experiences they frequent.

Developer and Partner Trust

Trust isn’t just about customers, it’s also about developers and partners. Sometimes you’ll see institutions “experiment” their way into developing a platform. At Capital One, our approach to API product development can be summed us as fail fast, learn, iterate. If we design an API that fails to connect with the developer community, we either retire or rework it. This philosophy can be seen in our approach to Experimental APIs and in our choice to retire the original Swift ID API in favor of our trio of Digital Identity APIs. If the community does not react to a product, it’s better to remove it and move on to an implementation that will meet need their needs. Institutions that have a culture of innovation and a fail fast, learn, iterate philosophy are going to be more successful than those that cling to an idea hoping that eventually the masses will come. Those failures are really learning opportunities and should be celebrated as them.

At Capital One, everything we’ve opened up externally has been battle tested by our internal developers and product teams, going through rigorous review and governance processes, and in some cases, years of proven use in our own consumer applications. As a digital bank, the ability to reliably and quickly connect customers to their Capital One experiences is a top business priority. All our consumer applications, as well as the internal APIs powering them, run on the same platform as our external APIs. There is no different standard for internal or external services, because to us they’re one and the same.

We want to make sure we’re helping our partners be successful in their ecosystem, and that we’re doing it as a brand they trust to have their back. With developers and partners, this kind of credibility matters a lot. They need to know that you won’t compete against them, that the service will be reliable, that APIs will be retired with full transparency, and that two-way communication will always be prioritized.

Regulatory Trust

When Capital One set our platform strategy and opened up our services to a new segment of partners and developers, it was because we wanted to be part of the newest, most innovative customer experiences they were building. Given the regulated environment we work in, we first had to meet certain requirements and start a two-way conversation with our regulators. Yet again, in this situation trust is established when you can be transparent and show the end destination you’re trying to solve for. This isn’t a matter of checking off boxes, this was a learning process with a lot of feedback along the way.

Conclusion

I believe the success of the Capital One DevExchange platform stems from creating valuable, trusted APIs and open source projects that serve the needs of our integration partners and developer community. By creating a space to access our externalized fintech APIs, we can co-create experiences and reach customers we’d otherwise be unable to with internal resources alone.

What are your thoughts about trust in platforms? Do you agree or disagree? You can reach me at geek@capitalone.com or on Twitter at https://twitter.com/nanwar.

DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2018 Capital One.