 Oh, so I guess I'm not using this. Oh, I can use them both. All right, cool. Hi, guys. So thanks for the introduction. I hope everybody's fan and drunk and everything. If you haven't had the chance yet, don't worry, you can go back for more later. We're going to try and keep it chill, all right? OK, cool. So just to give you guys a quick overview of what's going to be happening tonight, I've attended one or two API craft meetups before. And one thing I've noticed is that it runs the gamut, right? There are people who want to know about the business aspects and how the API strategy works. And then there are ones who are like, I want to see code and find out how to actually use the stuff. So today I will make the ill-advised choice of trying to please everybody at once. So here's how it's going to go. I'm going to talk about DBS's API strategy and why we're doing all of this in the first place and how we see it going forward. And then I'll get a little bit technical, the general steps about how to use our portal to get started with the APIs, and then that quick kind of technical, like this step, then this step, then this step, then this step, right? Cool. And finally, we'll talk about how you go to the production, which is also a very good time to talk about the challenges that we face, because we're going to be upfront with you guys. It's not all roses as well. So who better to hear it from than us, right? Also, warm welcome to all the DBS folks in the audience. We've run a couple of DBS-only developer events. I thought it would be a good idea to mix the DBS folks up with the external folks. If any of you external guys want to find out what it's like working in DBS, find somebody from DBS and talk to them. OK, cool. And now, to start off, maybe a little bit of context, this is me on my very first day of work, which also happened to be the day that the API is launched. Over there is my partner in crime, Alan. Yes, he's contributing over there. I see you, Alan. We went to Silicon Valley together for the NUS NOC program, and somehow ended up back in the same company. So I worked in the startup there. I worked in VC. Before this, I was in a government-backed VC. So I'm all about the startup stuff. And now I'm trying the corporate innovation stick to see whether it works out, because we worked with a lot of corporates, right? So if you want to find out anything more about that as well, come talk to me. OK, DBS has a thing. Singapore has a thing about acronyms, right? So DBS, APIs, LNBL. The last one is perhaps a little bit more relevant to our discussion today, and the API strategy in general. And that's our very new shiny tagline that everyone has see plastered all over the buses and TV ads, and Instagram ads, and Facebook ads, and what have you. It's Live More Bankless, right? And the story about this is that they actually tried a couple of iterations of this, a couple of the edgy versions, and they ended up with this. Because most people are like, oh, it's a bank telling us to bank less. What? Yeah, but it's actually a little bit more... You'll see what I mean. OK, take this case example, right? Where do you spend your time? And not just where do you spend your time, where would you prefer to spend your time, right? So on the left, we have our walled garden kind of stuff, right? So you log into DigiBank, your lifestyle, your ID, or Payla. Some of you might not have even heard of lifestyle, right? It's the app where you go into get deals and that kind of thing, right? And this is kind of what DBS thinks of as how banking used to be, right? The whole reason apps came about is that we want to make it life a little bit easier for you, right? So I don't need to walk into a branch to do this. I can do it on my phone. And so what's the next step of that? The next step is that maybe I don't really need to go into my app to do this. Maybe I can do it anywhere else. Maybe I can do it within all of these platforms instead. And the only way to kind of make that happen is with the APIs. So that kind of forms a backdrop of what DBS wants to do. So if you see all these guys over here, all of them were partnered in some way or another using some function of our APIs or another, right? Say with Gopion, local coffee people, OTH, it runs on our Pela APIs so that you can pay for your coffee. And all of them plug into Facebook Messenger, which is great because they don't need to download random apps. And it's all on that platform. You can go to Property Guru and find out how much of a loan can I take. So before I go browsing for a house, why not have DBS tell me how much I can afford first, right? We have active parts where you can redeem your rewards. Instead of the old method of go to the website, redeem my rewards, get a coupon in the mail, take the mail, go to the shop, redeem the coupon. That's dumb. So why not just offset my purchase using my points? One point equals one cent, and then that's it. It's straightforward. That's what everyone kind of comes to expect. It's also what we run with circles, where you burn points for data. See, it's straightforward. It's great. And you don't need to see DBS in this process at all. Kind of. And so how do we do that? APIs is how we do it. So for the less technically inclined ones in the audience, of which I'm sure there might be a couple, think of the APIs as basically just chopping up and puzzling out the functions that you can already find within internet banking. We get a lot of questions about how do you handle security and authentication and its APIs in an external area? The answer is that we already kind of have those structures to manage risk in place, because we're a bank. And by puzzling out the services as microservices, then we just apply the same kind of risk management logic to those frameworks. So for example, SoCache is a partner of ours. You can use the app to withdraw money from shops instead of withdrawing money from ATMs. And so that uses our funds transfer API. So you can kind of think of it as taking like a nice big slice out of your internet banking app and just shoving that piece into SoCache. If you want to transfer money using funds transfer on DBS, you will need to type in your username and password. You will need to use your 2FA. So in SoCache, it's exactly the same. And so that's kind of how the security is handled in that sense. I mean, of course, there's like OAuth and all that kind of thing associated with the security of how the API actually works. But generally, like that risk metric follows our internet banking sort of metric as well. Yeah, so this is kind of how it looks like in practice for the SoCache app, which you guys should totally download and try it out. They give away like $1 or $5 every so often, which is nice. So say, for example, you say, how much cash do you want? And then you say, get cash. And then what happens is that an iBanking page pops up. This is actually something that we mandate to our partners. So a lot of them are like, can we have it in a native browser altogether? And we kind of get it from user experience kind of angle where it looks a little nicer, less jarring to kick in and out. But on the other hand, the kind of the potential for phishing is a little bit higher that way as well. And so what we want to do is to actually have that URL and everything pop up so that they can look at it and be like, OK, this is actually in DBS. Yeah. But once you do that, then you can have the APIs that pull down the list of deposit accounts and all that kind of things, which you guys will see in action later on and can try it out for yourself using our handy sandbox. Cool. All right, so now we're at the getting started stage. OK, API functions are nice. The need, the cool, where do I begin? So the first general step that I would advise is to figure out what functions you actually need. And we're very proud of the very large number of APIs that we have, and that's great. But you need to figure out what works for you. Otherwise, you're just going to browse through that list of 200 and just be completely overwhelmed by what you see. Generally speaking, the APIs that we see that are demand fall into three broad categories. We have the ones that have to do with payments. These tend to be the most popular, just because. So rewards, which allows you to burn points for dollars and cents, fund transfers, which of course is entering a rather interesting space now that pay now is a thing. And of course, good old Pela. We actually took down the Pela API for maintenance a couple of days ago, and people have been bringing us up wondering where the Pela API has gone. I did not realize people like the Pela API that much, but it's nice to know. Also, a side note is that it's important to use the right tools for the job as well. So if any of you ever email developers at dbs.com, which is kind of like our email help desk support line, one of the people behind it is me. So I see all the weird random requests coming in, and every one of you who has ever complained, that's me behind it. And some of them are like, oh, how do I enable credit card acceptance, for example? And it's like, oh, well, that's not really an API thing. You can just go to a payment gateway. So it's important to use the right tools for the job as well. There are some cases where you don't even need to use an API, where maybe pay now is the better solution for you. And so that's something that I've answered many a question about. OK, so that's payments. The other one that we have are the account information. So for example, with Property Guru, with the home loans, when you call the rewards API by necessity, you kind of have to call the cards API just to find out what cards you have before you find out what rewards you have. And Deposits, which is also kind of an intermediary step on the fund transfer. But it's helpful if you want to know how much money you have in your bank account at any one time. And then after that, you have the sort of what I'm just calling the utilities because the miscellaneous APIs. Parties is an interesting one. So parties allows you to pull down the profile of a user within DBS. So it's kind of like a pseudo KYC tool in that sense. Because all that information that you have, that DBS has about you, like your name, your salary, ethnicity, your birthday, and all of that is vetted by virtue of you having a DBS account. And you can kind of pull down all of that information. In the basic instance, it's great for filling in forms. But we've seen a lot of requests to use it in all sorts of weird, funky, interesting ways. Bill payments is there because sometimes you want to pay IRAS money. And that's always useful to have. IRAS wanted to use that one, talking to them about it. And FX rates, if you happen to need foreign currency conversions, is also one of the more easy APIs to call. And that's nice. All right, cool. So now we'll talk a little bit about the sandbox features, where you need to click to generate what to get started where and how to use those what's to generate what. Simple. OK, so these are kind of the overall steps that I've kind of put together on calling a DBS API 101. So fun story, I was not from computing. I do not know any computing. But I bashed my head against the wall to learn JavaScript with the objective of being able to call a DBS API, which I've done. So hooray. So all the code snippets later are provided by me. And they're probably extremely amateur, so they'll make fun of me. But I had like two months to do that. So if it's good enough for a beginner like me, I'm sure it's good enough for other beginners in the audience. Which would be nice. Also, all of these steps, I packaged them into like a handy dandy kind of reference booklet. I'll give you guys instructions on how to access these instructions later on. So you don't need to take pictures of every single one of these slides moving forward, right? Cool, OK. So step one, sign up, duh. So if you want to start calling the APIs in the sandbox, you're going to need an account. So you should do that. Sometimes the emails get sent to spam, so retrieve them from there while working on it. OK, so the next general step that you want to do is that there's a tab on top called My Apps. And that's where you want to go into it. So My Apps is where you will start generating like the credentials that you will need to call your APIs. Oops. OK, so once you create a new My App, you get a bunch of things that you need to set up. One of the most confusing ones for people is the choice between Trusted Partner and DBS Customer. Trusted Partner, I don't know, at this point, we're taking it off because Trusted Partner is usually for internal DBS usage, where everything is kind of pre-veted. So it's a use case where it's not like just now where you can see the customer log in and type in his password. Trusted Partner, none of that happens. As you can imagine, we don't give that kind of authority out to anybody very lightly. So generally, you don't touch that. What you want to do is to select Internet Banking Credentials or Card Banking Credentials. Internet Banking Credentials should be familiar to just about everybody. That's why you use the login to your Internet Banking. Card is a little bit more esoteric. So in some cases, people might be DBS customers, but they don't have Internet Banking Credentials for whatever reason. But they probably have a card. So they just need under the last four digits of the card number and their pin, and that serves as authentication as well. So that was a special request because they were like, what if people don't have Internet Banking? It's like, OK, that's fair. And then you have your redirect URI, your URL, sorry. And that's kind of your environment where after authentication, you need to go back. So after you type in your username and password, it needs to know where to go back to, and it will go over there. Oh my god, it's Haofeng. Everybody say hi to Haofeng. He's my next-next partner in crime. So I guess we have more helpers, which is great. Other things to take note of is that you have a client ID and a client's secret. So those are things that you need to pass into your request later on. Then the next step is to pick your API and browse the documentation thereof. So in this case, I will be looking at the party's API, which is one like the Neeta wants to call, and it's a basic no-to-FA. You just need one FA kind of get request. So that's a nice place to start and probably around what we have time for today. OK, so the first step is to redirect to OAuth. You can find all of this in the documentation, but basically, you need to take your client ID and client's secret and code in base 64, shove it into the URL provided over here with your client ID, and that will spit you off to this page. And then your user will type in their username and password, click Login. And that's where a redirect URL comes in. It spits everything back to your redirect URL with this access code attached to it. So it will be stuck onto the end of your code like that. What you need to do is to then take out that code and call our OAuth API. And that will get you access token. So that's, yeah, it's all of that. It's in the documentation again. But basically, the response that you get will be a massively long string of text, which will look something like this, this whole pile of gobbledygook right here. And that is your access token. And then once you've got that access token, then you can call your API. So this is a basic 1FA kind of thing. One thing to note is that it's a little odd, but when you call the OAuth API, it returns you the access token. It also returns you party underscore ID. And party ID is one of the things that you need to pass into the body when you call on the API. But party underscore ID is distinct from party ID. It's just one of those developer things. So the party ID can be found right at the end of your access token after that power. Yes? Should I ask a question now or later? I don't know. Ask it now. Why not? Yeah, I'll help. Is that GWT? Yes. Yes. So which means that I can decode it and know what my identity is? Yes. I haven't figured out how to do that, but you can ask one of them. OK. Cool. Yep. And then after that, yeah. And then basically you're done. So once you call this API, and then you get a response that looks like this. I mean, it's in JSON. Then once you format the JSON, then you get all of this good stuff, which tells you, oh yeah, this is basically all the data, which is great. OK. So that is the basic one, two, three, four steps on how to get started calling a party's API. Here's an introduction to some of the other tools that we have on the platform, because it's never as simple as the steps to make it out to be. So step four, debug. Try it. It's a very handy function. What try it does is that it gives you kind of like a GUI pseudo postman, where you can kind of click through the different steps, and it shows you the body of everything that's being called at any point, and what is being posted, and the body, you know, that kind of thing. It's handy. The other handy debugging tool that we have is the reference app. So it's one of the tabs on top called ref app. These are sort of customer journey suggestions, where people, a lot of people ask us, OK, cool. You've got the APIs. What do I do with them, and how does it look like in practice? So here we have, well, I guess now it's three different sort of customer journeys. So they are modeled after some of our launch partners. So funds transfer follows so cache. So the process of how would I log in, and then what would I need to type in, like the recipient account number, where does the 2FA come in, et cetera, et cetera, et cetera. Anything about that is that you've got this little API console at the bottom that looks like this that shows you what happens at each step. So it shows you the APIs that are being fired, what the headers look like, what the responses look like, and then you can kind of muddle your way around from there. Yep. OK, so now that I've bogged your mind with all the technical talk, it's back to the business stuff. So now that you've successfully tested everything on the sandbox and everything is fine and amazing, what is the next step? You want to go to production, right? You want to use this in real life. Yeah, so to production. And beyond. Except that it's not so simple, unfortunately. And so I probably have to watch a little bit about what I'm saying, because this is being recorded. And if any DBS folks who are very fussy about this don't like what I say, you might not see me the next time you're here. But I'll try and explain it as best I can, right? So what we have here is my rather crude analogy of some of the challenges that DBS faces moving forward. And a lot of this should actually not be a new revelation to many of you, right? What we have is a very shiny, shiny front end, which are the APIs, right? Which are modern, which are very scalable. It's fantastic, right? The problem is that on the back end, things aren't quite as shiny, right? So we've got a very complicated plumbing system, a lot of which tends to be very old. And of course, we've got legacy processes at the back as well, some of which is a product of the plumbing and some of which just happens to be legacy processes, right? The upshot of this, unfortunately, is that it means that we can't quite onboard everybody on the production as easily as we like. So we've had to turn on quite a number of people applying to go to production just because the kind of internal effort that we need to sort out the plumbing and get them onboard just makes it like too time-consuming or prohibitively costly to make that happen. Which isn't to say that it's just there for show and will turn away everybody. Right now, we kind of have to prioritize for the deployments that give us kind of the greatest effect. And unfortunately, that happens to be larger companies or fast-growing startups, that kind of thing. Individual developers, for example, if you're trying to develop a project and you're like, oh, I want to use this, it's a nice way to manage my finances. Like, well, my aspiration is that DVS gets there one day, but that day is not today. Yeah. So one thing that I was very conscious of and I was talking to John about it is that what I don't want to do is to set up the expectation that you guys will just jump on production right away. Unfortunately, we're not quite there yet. Please be patient and deal with us. We'll get there eventually. DVS has gotten here already, so it's just a little leap forward. But just to kind of elucidate the points about the challenges that we face. Broadly speaking, it's around there are business challenges and then there are technical challenges. One is a boardroom where you feel like jumping out of the window and the other one is when you pry out the circuit boards and they're bugs. Yeah, it's quite that. Okay, so here's the deal. I've kind of told you guys about what are problems that we face and since I've got all of you very smart people in the room, I was hoping that I could get a hand with you guys and helping to solve them, right? So, yeah. Don't read too deeply into it. Basically, shiny golden front end, very complicated plumbing and a bunch of manual processes sometimes. Yeah, yeah. Yeah, okay, so I'll talk a little bit about kind of the challenges that we face but I was hoping to get some crowdsourcing done so if you guys don't mind whipping out your phones once again, go to menti.com and use this code and then we've got a couple of questions there. That we'd love to get your answer on. And I, oh, 564782. Yeah, thanks. Hang on a second. 564782. Sorry, I'll pull up like the actual page in a second. It's also kind of like an object lesson if that helps. Yeah. Oh, wait, hang on. Yeah, sorry, I'm meant to like talk about the questions in a bit. I don't know, hang on, hang on, hang on. But thanks for the enthusiasm. Yeah. Okay, so here we go. Okay, so. Here we go. Okay, so just to elaborate on those previous questions before and in kind of an object lesson right around here. One of the problems that we have is that what you have is we're a banking organization, right? We don't sell tech as a living, right? And so the concept of, say, paying for an API call is something that's, you know, new to the product guys, or at least the banking product guys who are the ones who currently hold these APIs, right? And so one thing we've been telling them is that, yo, you guys should like try pricing out the APIs. And then it kind of becomes like a little revenue stream, but they sometimes they're like, wait, people pay for APIs? So here's a question. We get a lot of demand for the funds transfer API, right? Mainly because, you know, you don't need to pay Visa master fees in that sense to receive funds. So how much would you pay for a DVS API for like, for a single funds transfer? So, you know, on this end, they say I would only pay for it if it's entirely free. And on the other end, it's like, I would pay like a dollar for it. And I'm capping at a dollar because anything else seems rather excessive. So, yeah, so we can kind of see the number of people answering at the bottom. So we'll give it, we've got what? I actually need to count how many people are here, but we've probably got more than this. So let's wait for it till it hits 30. And if you want to answer after it goes to 30, that's fine, we'll just skip ahead to the next one. Although we seem to have a nice, like people pay like 10 cents a call. Cool, okay. Up next. Okay, so that's kind of like the business end of the equation, right? So here's the other question. Like many other organizations, we have our technical limits as well. I'm sure my technical colleagues in the audience would say no, we're super human and we can handle anything that work chose at us, but probably that's not the case. They would like to go home on time. So we've been thinking about maybe open sourcing or like community development of some of our code. That's an initiative that I in the innovation group might be considering as a nice way to kind of push forward, right? So, would you be interested in developing open source code from DVS? So say for example, if you were to make an SDK for these APIs, would you be more interested if we supplied the code first, or would you be more interested if, you know, you guys created it by yourselves and you just kind of like self govern that kind of development in the open source so you get kind of way that the open source community does? I don't know. Do you tell me? Will you give the patterns? No. I mean, open source is kind of a licensing and that means there is, yeah, it's a non-license. It's copy left, but yes. MIT or... Yeah, exactly. All right, cool. So people seem somewhat interested. That's good to know. All right, and last question. Don't worry, I really won't take up too much of your time. I'm doing this. Is that... Oh, hang on. Okay, there we go. Okay, so the next thing is that we kind of... It's... Expecting developers to work for free is not cool, right? So maybe we want to set up a system where we reward the community with bounties or whatever to help create stuff for us. In that case, how much would you guys expect, if we put a bounty on our website that says develop a Ruby SDK for X amount of dollars, how much would that X have to be to entice you to take it up? Answers are coming a bit slow for this question. Everybody's like, what is my price? I was looking for 100K, but that's only 10. Oh yeah, sorry, the metimeter kind of caps it over there. Expect to get the code supplied by DBS and code... Okay, so in code supplied by DBS, the assumption is that we will create something that's like incredibly basic and just kind of seed the community with that. Community-driven means that you pretend like you can't rely on DBS and you are like, I just need this for myself, but I want to share this with all of my other friends who I think would find this useful. Oh, wow, there's a lot of answers all of a sudden. Okay, cool, thanks guys. It's been very helpful. This will probably come up in a presentation somewhere. I hope you guys are cool with that. It's all anonymized anyway, so that's neat. All right, cool, thank you. So now we're at the end of that, and it's on to the next step. Okay, so the next part of this event is gonna be a little bit more free form, right? So we've got until kind of 8.30, where we'll kind of like put the wraps up on everything. But generally what we have in mind is that you guys might want a chance to get hands-on on the APIs yourself, like whip out your laptops and start having a crack at it, whether in postman or whatever, right? So we've got a couple of options for you. How I'm gonna split it up is that we've got kind of three room segments over here. Now that my friend Haofeng is back, he can help out. So, let's say you wanna try something related to parties, or assuming you get past all of whatever, right? You wanna try something, parties? Come over and look for me. If you want something to do with fun transfers, look for Haofeng over there. Haofeng Waveface. Haofeng, yay, Haofeng's a star developer. And then FX rates. Look for Alan, who is over there drinking his chang. Wave, Alan. Yes, Alan pretends to be less technical than me, but he's full of crap. Okay, and of course, we won't leave you high and dry. So as I mentioned, that little cheat sheet that I mentioned with all the little code snippets from my very, very amateur code snippets. So for those of you who are not DBS staff and can access Facebook on this internet network, you can head over to this bit.ly and find that little PDF chunk over there. If you would like to get started with some sample code that isn't made together of spit and duct tape code, Haofeng has very kindly made his code available on GitHub, so you can follow that link right over there. And for DBS staff, because you cannot access Facebook, I've put it on Microsoft Teams. So you can join the group with that code over there, and you should see the file that I've uploaded with those hint snippets and all that. So I will leave this up, I will leave this up here. And in the event that you feel like the code isn't for me and you just want to hang out and chat, that's cool too, grab more pizza because we've got quite a bit of that left. If you want to talk to DBS guys, you'll find some of them around the place. My friend, Tansen, is over there, Eugene, they're cool. Yes? Another question. Yes? So that's more because the API, you're thinking of the OR piece. Yes. I believe most of the DBS are OR. Yeah. Who protected the sets. So you require the user's dedication for whatever app that you call your API. That's right. Do you guys provide a portal within the DBS site for me and the user to know which of the apps that I have approved and who they can withdraw from the S&M I wanted? That is thank you. Yeah. Facebook, Facebook has an issue with the data. Yes. I think also now they have emphasized that you have the right to revoke your rights with any application to pull your data. You have full view of what you have, what permission you have. Do you guys provide it now? Right now? No. But it's certainly something that we have discussed. Yes, yes it is. Yep. Yep. Okay, cool. So feel free to break out or say where you are. So once again, parties, fund transfers slash deposits, FX. If you guys wanna shuffle, then go ahead. If not, you recognize the three of us and you can come over and find us as well. So I will hit you guys back up at 8.30. Yeah, see you all around. Now if you wanna talk to me about like business-y stuff, that's cool too.