Designing better APIs for modern treasuries

Application programming inter­faces (APIs) have dramatically reshaped the treasury user experience across industries.

Corporate treasur­ers have begun to configure APIs for their own payments, bookkeeping, cash flow, and reporting purposes, among others. But the industry is going one step further by using APIs to automate the treasury function, provide more accurate forecasting, and enhance the internally facing user experience.

Goldman Sachs had the advantage of a clean technology slate and was thus able to imagine and build their APIs without the overhang of legacy systems. As such, their APIs provide a strong foundation for treasury departments going forward: nearly 99.9% uptime, cloud services, and modern tooling. But these results did not come without significant forethought and design.

The foundation of their APIs was the technical platform that lies beneath, and the process of polishing each API before rolling it out externally. Building an API is relatively straightforward; building a thoughtful set of APIs on a strong technical plat­form is challenging and expensive.

“The attractiveness of building APIs is undeniable, but getting to smooth-running, relatively glitch-free APIs requires work you do not see as a user—and that is the point. You do not want the user to do the work,” said Luc Teboul, global head of engineering at Goldman Sachs TxB.

Since APIs depend on their underlying infrastructure, their design, creation, and develop­ment require careful technical consideration.

Reviewing the technical choices

The process of sorting through the many considerations and technical choices begins with a simple ques­tion: what do you want the API to do?

This determines what in­formation it collects, what it connects to, and what happens as a result. Importantly, the user must be involved in answering all these questions. Users and developers working together can avoid com­plexity and choice paralysis, which tend to derail the development of APIs or undermine them once they are rolled out.

For example, when designing their payment API, Goldman Sachs had to decide whether to allow a client to pay via different payment rails with one or multiple APIs. Their team concluded it did not make sense for a client to have to relearn a new payment API just to access a different rail—so they built a single API for this function.

In another case, they created sep­arate payment template APIs for ‘funding accounts’ and ‘payment accounts.’ Despite their functional sim­ilarities, these accounts would be utilised in different ways and in different contexts, and therefore separate templates would be needed.

Feedback & refinements

The process for reaching these conclusions was deliberate: Goldman Sachs would design an API first, seek feedback, and make any necessary fixes.

Rather than borrowing an existing internal API, the bank designed one to function independently of complex­ internal systems. Subsequently, a structured review of the design forced revisions that account for some of the most critical technical considerations and challeng­es likely to emerge later.

Users and user input could then be integrated into the review process, driving further improvements. By steadily polishing the APIs in this manner, Goldman Sachs gained insights that could only emerge from real user feedback.

For exam­ple, due to user feedback, they put foreign-exchange details in their payment status API. Goldman Sachs’ team distinguished fund­ing from payment templates due to their differ­ent sign-up processes and adapted their data platform to give easier access to new types of data.

By building in a user feedback loop, Goldman Sachs were able to place the user at the centre of their design process. In certain cases, they would create personas for their clients, recognise their unique qualities and needs, and seek out approaches that would work for them.

Specific technical issues

The process of designing and developing APIs re­volves around a set of technological issues that can determine user uptake, business impact, complexi­ty, and business execution. The best-designed APIs follow a set of patterns—naming, response codes, pagination, and so on.

The rea­son is simple: consistency and pat­terns make for a better user experience. For example, when creating a single API for all payment rails, the goal of a consis­tent naming structure forces a designer to confront the fact that “paymentAmount”, “Amt,” “Amount,” and “payment_amount” are all used to describe how much someone is paying someone else. The chal­lenge is further compounded when a particular word has multiple meanings, depending on context.

Because Goldman Sachs created new APIs without legacy naming systems and protocols, they were able to create standard, English descriptions for all fields. When unsure as to the correct direction on a nam­ing question, the bank asked corporate treasury professionals for their input.

Clients often want to know the resource type and objects offered by an API system. Getting this right is challeng­ing, but Goldman Sachs had the advantage of starting from scratch. The team then started making payments for the rest of the bank, followed by be­ta-testing a client-facing API that helped them prioritise features clients cared about.

This highlights the critical issue of how they handle API upgrades for clients. The bank adopted an approach that allowed it to enhance the user experience without dropping clients who had locked in on prior versions of their APIs. Ultimately, this focus on the user has simplified sev­eral other technical issues, including documentation.

The team matters

The authority, experience, commitment, and compo­sition of the team designing and developing APIs matters. Goldman Sachs recognised meaningful benefits by assigning API ownership across a team of dedicated engineers, product managers, and sales and busi­ness stakeholders.

Rather than seeing the API as a technical plug-in or product extension, they treat­ APIs as products in their own right, building them as they would build stand-alone products. This focus, combined with the natural advantages of building on a new foundation, provided the bank with the freedom and room to create APIs that deliv­er what they are supposed to.