apidays LIVE JAKARTA - Connecting the Digital Stack Productising APIs: A journey in how we built API products in SEA Mike Dickinson, Chief Product Officer at Brankas

1. Productising
APIs
A journey in how we built
API products in SEA
Mike Dickinson
CPO, Brankas
Sep 2020
APIdays Jakarta

2. State of Open Banking in SEA

3. Open Banking APIs in SEA (minus Singapore) is still early days.

6. CONTENTS
1. Product Development Lifecycle
2. Problem Statements, Hypothesis and Solution Statements
3. Validating Hypotheses
4. Epics
5. User Stories
6. Prioritisation

8. Supply

9. First step of our journey
There was a problem. We realised that there was a need to build
infrastructure to ‘open’ core banking systems via Public facing APIs.
We started going to banks and building Open APIs based on their
core banking infrastructure to expose multiple use cases.
● One of which is a funds transfer mechanism
These projects are complex, because all banks are at different stages
of their Open API journey.
I will refer to one of our Direct products as the example use case in
reference to the rest of this presentation.

10. Basic
No open API infrastructure;
Core banking integration, Microservices
API, API server and Cluster service.
Intermediate
Having core banking integration and
several open APIs available but no third
party onboarding tools.
Advanced
Having core banking integration and open
APIs available and third party onboarding
tools but looking for more API consumers.
We realised 3 levels for a banks readiness for Open Banking
APIs

11. Security &
Development Tools
High Level Architecture
Developer Enablement for APIs
Core Banking Integration
Microservices APIs
API Analytics & Monitoring
Brankas Core Products (API Reseller)
Core Banking
Cluster
Service
BRANKAS
BANK
API Gateway (Apigee, 3Scale, IBM API Management, Akana, Kong Enterprise) Optional
Auth + Open API Endpoints

12. Demand - Internal APIs

13. Preparing for Demand
● Built APIs internally in aggregate
● We did this to ensure internal consistency
● Allowed us to dogfood faster on what was coming up
on our future roadmap

14. Direct Example
● Bank selection, so we can handle multiple banks
● Retrieve all available banks that are integrated
● Triggering funds transfer
● Handling of various TFA flows
● Retrieve transfer status (internally)

15. Customer facing APIs

16. SURFACING APIs TO OUR CUSTOMERS
We created a simple end point for our Funds Transfer
product based on our internal APIs to solicit our own IDP
Considerations
● Security
● Onboarding (through a single endpoint)
● Aggregation of bank flows (no consistency due to lack
of Open Banking standard)
● Companies that have developers on hand (usually
Medium - Large co.s)

17. BRANKAS DIRECT DEBIT
DIRECT IDP / AUTH
Client invokes Direct
oauth2/tokenPOST
v1/checkoutPOST
Direct sends a callback
to client informing
them of the new fund
transfer
v1/transferGET

18. APIs to UIs

19. PROBLEM
A lot of companies in the Philippines and Indonesia do not
have the technical resourcing means to build to this
endpoint
So we decided to leverage both our internal APIs and
Public APIs to help solve the problem of painful funds
transfers for micro- and small businesses.

20. SOLUTION - WE CREATED PAY

21. In conclusion
● We biased towards persona types and what they needed
● Focused on being API first
● Owning the UX for aggregated APIs
● Even with simplicity of integration on our external APIs,
onboarding takes time
● The market is very visual when trying to understand OB
(e.g. Pay, but actually Direct)

22. Q&A