ادامه بخش اول
ایجاد ارزش از طریق رابطهای توسعه نرمافزار(API) باز
اغلب فعالان بازار دیجیتال در جهت تحقق اهداف کسبوکاری خود و در نهایت ایجاد ارزش برای مشتری، از تکنولوژی رابطهای توسعه نرمافزار(API) استفاده میکنند. آنها میدانند که استفاده از API در باز ساختن سیستمها (به دنیای بیرون) ضروری است و به یاری آن میتوانند تجارت را به سمت سرمایه هدایت کرده و موجب ایجاد ارزش مشترک برای مشتری نهایی در اکوسیستم و به اشتراک گذاری هزینه و مزایا (شامل سودها) بین طرفین درگیر گردند.
توانمند ساختن شرکا تجاری در ساخت نرمافزارهایی برروی پلتفرم باز
فیسبوک، آمازون، eBay، PayPal، توییتر و گوگل از جمله مثالهای این مورد میباشند. توسعهدهندگان میتوانند قابلیتهای موجود را دوباره مورد استفاده قرار دهند یا از منابع داده به منظوربهبود نرمافزارهای خود بهره ببرند. این امر هزینه را کاهش داده و دسترسی سریعتری به بازار (time-to-market) فراهم میآورد اما برای توسعه دهنده ثالث نیازمندیهای دیگری بوجود میآورد. این شیوه، ایجاد ارزش مشترک برای توسعهدهندگان API، شبکه توزیع وسیعتر، دادوستد و به حداقل رساندن هزینههای نوآوری را به همراه دارد که همگی توسط شخص ثالث اجرا میگردند.
اشتراک اجتماعی برای مقاصد بازاریابی
مثالهای این مورد شامل فلیکر، Delicious، توییتر، یوتیوب، لینکدین و فیسبوک هستند. منظور از به اشتراکگذاری اجتماعی ارسال عکس، ویدئو، آگهی محصولات و لینک وبسایت برای برقراری ارتباط با دیگران در یک شبکه اجتماعی است. به اشتراکگذاری اجتماعی برای عناوین تجاری و مقاصد بازاریابی و ایجاد دادوستد وبی، شیوهای بسیار موثر است. بانکها میتوانند با استفاده از ضوابط اشتراکگذاری اجتماعی، جوامع کاربری ساخته و آگاهی و وفاداری مشتریان به یک برند تجاری را حفظ و افزایش دهند.
یکپارچهسازی محصولات و خدمات در میان پلتفرمهای مختلف
گوگل و eBay مثالهای این مورد هستند. این اتحاد زمانی ایجاد میشود که چندین فعال بازاری با هم کار کنند تا خدمات مشترکی را برای یک مشتری عرضه کنند. هر یک از این فعالان بازاری، برای ایجاد ارزش فراهم آمده توسط سرویس، موارد مشخصی ارائه میدهند. هزینه پرداخت شده توسط مشتری بین اعضای متحد صنف تقسیم میشود.
مدلهایی که در بالا تشریح کردیم نه تنها همکاری بین طرفین را ارتقا بخشیده و توانمند میسازند بلکه امکان ایجاد گزارههای ارزشی کاملا جدید و مجذوب کننده را فراهم میآورد. سهولت استفاده، انبوهسازی اطلاعات و محصولات و ارتباط مستقیم مواردی کلیدی در سرعت بخشیدن به این پروسه هستند.
در بخش بعدی چند مثال از فعالان بازاری را که توانستهاند با موفقیت استراتژیهای API باز را به کار بگیرند عنوان میکنیم.
مثالهایی از استراتژیهای موفق API باز
نمونههای فعالان شناخته شده بازار دیجیتال در خارج از صنعت مالی شواهدی ارائه میدهد که نشانگر موفقیت آمیز بودن استراتژیهای مبتنی بر API باز است. پنج مورد استفاده موفق از API باز توسط فعالان بازار دیجیتال در دهه گذشته مورد تجزیه و تحلیل قرار گرفته و به طور خلاصه در جدول شماره ۱ عنوان شدهاند.
جدول ۱٫ شرکتهایی که استراتژیهای API را با موفقیت به کار گرفتهاند (غیر جامع).
نام شرکت | علل استفاده از API |
Salesforce | رویکردی جدید برای دستیابی به مقاصد CRM آنها بوده و شخصیسازی و یکپارچه سازی Salesforce CRM را با جریانهای کاریشان آسانتر میسازد. |
توییتر | ایجاد ارتباط متقابل سودمند بین توسعهدهندگان شخص ثالث به منظور توانمند ساختن قابلیتهای عملکردی بیشتر، همچنین دسترسی راحت برای مصرفکنندگان فراهم میآورد. |
آمازون | با گسترش محصولات ارائه شده به دیگر پلتفرمهای دیجیتال، کاربران میتوانند از حجم بالای محصولات ارائه شده آنها بهره ببرند. |
لینکدین | ایجاد دسترسی به پایگاههای عظیم داده برای قادر ساختن مشتریان به اتخاذ تصمیمات بهتر با در نظر داشتن منابع انسانی و شبکه سازی حرفهای |
IBM Watson | تغییر جهت الگو به سمت یادگیری(دانش) ماشینی و پلتفرم پردازش داده برای اشخاص ثالث، مشتریان از موارد نوین مبتنی بر معلومات خاص یک حوزه از طرفین ثالث سود میبرند. |
مثالهای ذکر شده در جدول بالا و مواردی دیگر، چگونگی بهره بردن یک سازمان از به کارگیری APIهای باز را نشان میدهند. تعداد APIهایی که به صورت باز در اختیار توسعهدهندگان قرار دارد رو به رشد است. آخرین تعداد تخمینی از APIهای باز ۱۵۰۰۰ مورد بوده است که تقریبا ۱۲۰۰ مورد آن مربوط به پرداختها است. APIها همچنین نقطه اتکاء “استراتژیهای پلتفرم” اکثر سازمانها در جدول بالا بودهاند. در بخش بعدی APIها به عنوان ستونی اساسی برای استراتژی کسبوکار مورد بررسی قرار میگیرد.
APIهای مالی درمقابل جنبههای فنی به توافق نیاز دارند
در بخش پیش چگونگی ساخت APIها براساس استانداردهای فنی پذیرفته شده در سطح جهانی را بررسی کردیم. با این وجود، واسطهگری فنی در دنیای مالی برای همکاری میان سازمانها کافی نیست: بودجهها و حساسیت دادهها در این امر بسیار مهم هستند و باید اعتماد را ایجاد کرد. شیوههای متنوع اداره داده، بعد دیگری فراهم آورده که در کنار انواع مختلف داده، برخلاف نوشتن داده شامل خواندن آن نیز میگردد. دادههای شخصی مشتری نسبت به دادههای بانک یا دادههای کلی مشتری، الزامات فنی متفاوتی را میطلبند. بنابراین به سطح کنترل بالاتری نیاز دارند. با این حال، بانکها هماکنون نیز تجربه دسترسی کنترل شده شخص ثالث را داشتهاند.
مثلا در هنگام ایجاد زیرساخت برای پرداختها و مسائل امنیتی و در هنگام واسطهگری با مشتریان و سایر طرفین، در آن سوی تکنولوژی، صنعت مالی ید طولایی در به کارگیری کنترل و استانداردسازی دارد. ما به طور کلی چهار بعد (حیطه) توافق و استانداردسازی در صنعت خود را تمیز میدهیم:
- قانونی: حقوق و تعهدات طرفین مورد نظر به منظور اعتمادسازی میان طرفین درگیر نیازمند توافق است.
- عملیاتی: برای اجرای یک API(پس از استقرار): عملکرد، عمرمفید، سطوح سرویس، پشتیبانی و غیره باید توافق شود.
- کارکردی: جنبههای مربوط به کارکردهای کاربر، معنا شناسی داده و غیره
- فنی: همه جنبههای فنی ذکر شده در بخش قبلی
امروزه، سیستمهای پرداخت (و مالی به طور کلی) چه یک بانک و چه مجموعهای از آنها، بدون توافقاتی درباره این ابعاد نمیتوانند به ایفای نقش بپردازند. بنابراین وقتی پای توافق و استانداردها در حوزه APIهای مالی به میان میآید، حداقل به حیطهای مشابه نیاز دارند. توصیههای بیشتر در گزارش گروه کاری بانکداری باز بریتانیا به تفصیل ارائه شده است.
نمونههایی از APIهای باز در صنعت مالی
جدول زیر هفت مثال استفاده از APIهای باز را در صنعت پرداخت اروپا نشان میدهد.
جدول۲٫ اولین پیشروهای به کارگیرنده API باز در صنعت پرداخت (غیرجامع)
سازمان | علل اساسی استفاده از API |
PayPal | گسترده ساختن خدمات تراکنشی به سایر پلتفرمها به منظور ایجاد دسترسی. این امر با توسعه دامنهای از APIها با رویکردی مشتری محور محقق شد. |
Crédit Agricole | APIهای فراهم آورنده تصدیق صحت، اعتبار و کارکردهای محل-محور. بهبود مشغولیت کاربران و روابط مشتری. نرمافزارهای اجتماعی و بازیها در کنار نرمافزار حامی مشتریان |
BBVA | APIهایی که به نیابت از مشتری، شخص ثالث را مجاز به دسترسی انتقال وجه و سایر خدمات مشتری، پروفایل و دادههای حساب و پروفایلهای کلی کارت میگرداند. نرمافزارها متضمن انتخابهای هوشمند مصرف کننده همچون زمانبندی رسیدگی ، توصیهها و خدمات انتقال وجه در طول استفاده از آن هستند. |
VISA | APIها در چهار دسته طبقه بندی شدهاند: روشهای پرداخت، خدمات عمومی، ریسک و کلاهبرداری و همچنین دادرسی. آنها بر مبنای تکنولوژی VISA برای مشتریان خود تجربه جدید تجارت الکترونیک را به ارمغان میآورند. Visa Checkout یک مثال از این APIها است. |
MasterCard | MasterCard ارائه دهنده APIهایی است که با در نظر گرفتن پرداخت، امنیت یا محل، کارکردهایی را عرضه میکند. این امر تجربه مشتری را بهبود میبخشد و تاجر به واسطه APIهایی چون API خرید Masterpass In-APP از نرخ بالای تبدیل سود میبرد. |
SWIFT | API یکپارچه سازی SWIFT (توسعه کد-رایج custom-code) و SWIFTRef API(مرجع جستوجوی داده) Alliance Access Developer Kit(دسترسی به منابع و سرویسها به منظور توسعه کاربران جدید به سیستم کسبوکار). APIهای SWIFT عملکردی پشتیبان برای سرویس پیام رسانی مرکزی فراهم میآورند تا انتقال بودجه را در سطح جهانی ممکن سازند. |
Fidor | با ایجاد دسترسی کنترل شده توسط دیگران به زیرساختهایشان، به منظور استفاده و بهبود خدمات، رهنمودها و لایسنس بانکداری از بینالمللی سازی تلاشهای خود پشتیبانی میکنند. Fidor در تلاش است API خود را تحت گروهی با نامهای API پرداخت، API اتصال، و یک API پیشین برای شرکای خاص بگنجاند. این امر دسترسی به منظور کنترل SEPA، انتقال(محموله) و کارکردهای مرتبط با بدهی مستقیم محموله(batch direct debit) را ممکن میسازد. |
بخش بعدی به تشریح ملاحظات استراتژیک در هنگام باز ساختن مدلهای کسبوکار میپردازد.
کنترل APIها
APIهای موفق بر پایه یک مدل کنترلی خوب هستند. این امر در مورد صنعت خدمات مالی(شامل APIها) نیز صادق است در این صنعت اشکال نظارتی مختلفی وجود دارد که اکثر آنها ابعاد تشریح شده در بخش پیش را تحت پوشش قرار میدهند. با توجه به هدف این مقاله میتوانیم اشکال نظارت زیر را عنوان کنیم:
- سازمان: از آنجا که تنها به یک بانک منفرد مربوط میشود، کوچکترین واحد کنترلی محسوب میگردد. سیاستهای شرکت، رهنمودها و APIهای عضویت در این دسته قرار دارند.
- انجمن یا اجتماع: استانداردهای سازگار و پذیرفته شده با به اشتراکگذاری گروهی ویژگیها و علاقمندیهای مشترک برای مثال انجمنهای ملی، پردازندهها، بانکها و غیره. آخرین کار انجام گرفته توسط گروه کاری بانکداری باز بریتانیا یکی از مثالهای این مورد محسوب میگردد.
- صنعت: استانداردهای سازگار و پذیرفته شده توسط یک صنعت کامل در مقیاس ناحیهای یا جهانی. استانداردهای SWIFT یک مثال استانداردهای صنعتی است. SEPA و PSD نیز در این گروه هستند.
- جهانی: استانداردهای سازگار و پذیرفته شده توسط صنایع چندگانه در جهان. HTTP/HTTPS به کار رفته در ارتباطات اینترنتی از مثالهای این دسته میباشند.
این دسته بندی در صنعت مالی شناخته شده است و در بخش بعدی مشاهده خواهیم کرد که چگونه APIها و کنترل آنها در امتداد این خطوط توسعه مییابند.
استانداردسازی API، پیشرو در صنعت پرداخت
در سالهای اخیر شاهدپیشروهایی صنعتی با هدف ایجاد استانداردهایی برای رشد APIها بودیم. شواهدی وجود دارد که بر حسب آن APIها احتمالا به یکی از الزامات ثابت بانکها تبدیل خواهند شد. جدول زیر مروری کلی از برخی از مرتبط ترین ابتکارات استانداردسازی API است. این جدول جامع نیست چرا که ممکن است ابپیشروهای دیگری نیز وجود داشته باشند که در هنگام گرداوری این مقاله کمتر مورد مشاهده قرار گرفته باشند.
جدول ۳٫ مروری بر پیشروهای استاندارد سازی API (غیرجامع)
# | پیشرو استانداردسازی | توضیح | کنترل | لینک وب سایت |
۱ | گروه کاری بانکداری باز بریتانیا (OBWG) | گروه کاری بانکداری باز UK استانداردی برای بانکداری باز تنظیم کرده تا طراحی فنی و مسائل زیرساختی را در کنار فرمالیزه سازی یک رویکرد برای مسائل حساس مشتری همچون توافق، ارائه حقوق دسترسی، واگذاری و تعیین اعتبار، رای دهی، اعتبارگذاری و نظارت را مد نظر قرار دهد. آنها در پی فراهم آوردن حداقل محصول ماندگار تا پایان ۲۰۱۶، و دادههای تراکنشی مشتری شمول در حالت مشاهده(غیرقابل ویرایش) از آغاز تا ۲۰۱۷ هستند. | ۱۲۱ تیم با پیشینههای مختلف | theodi.org |
۲ | CAPS | چهارچوب CAPS شامل سه لایه است: لایه PSD2(TTPها میتوانند از طریق یک API استاندارد به AS-PSPهای بسیاری متصل شوند، بانکها مطابق با قوانین PSD2 هستند)، لایه چهارچوب CAPS(کیفیت تضمینی اضافی اختیاری خدمات، مدیریت صحت اعتبار، کنترلهای موجودی حساب، مدیریت مناقشات و انتقالات)، لایه CAPS Plus(ارزش افزوده سرویسهای اضافه شده در ورای قوانین PSD2 برای مثال بررسی آدرس پستی یا سن) | اعضای موسس: Equens SE, Nets و VocaLink سایر اعضا: SIBS، PayPAL، Fidor، Bankgirot، گروه Isabel، پروژه بانکی باز | www.europeanpaymentscouncil.eu |
۳ | Open Bank Project | App store و API باز برای ساخت نرمافزارها و خدمات نوین مبتنی بر دادههای تراکنشی دارندگان حساب. بانکها را با متصل ساختن خدمات بانکی، توسعه دهندگان نرمافزار و دارندگان حساب قادر به عرضه یک اکوسیستم App شخص ثالث میسازد. | تاسیس شده توسط Simon Redfern و اداره توسط TESOBE | openbankproject |
۴٫ | ابتکار API باز | انجمن فنی باز متمرکز بر ایجاد، پرورش و ارتقاء فرمت تشریحی منبع باز خنثی و قابل انتقال یک ارائه دهنده | ایجاد شده توسط یک ائتلاف تجاری تحت نظر بنیاد Linux | openapis.org |
۵ | اکوسیستم پرداخت باز IXARIS | توسعهدهندگان برای ساخت نرمافزارهای پرداخت قابل شخصی سازی جهت استقرار برای بانکها از آن استفاده میکنند. تنها نرمافزارهای امن و قانونی در فروشگاه نرمافزار پرداخت lxaris منتشر میشوند. | IXARIS، با پشتیبانی EU Horizon 2020 تحت طرح نوین درهم گسیختگی باز | www.ixaris.com |
۶ | مبادله مالی باز(OFX) | استاندارد برای ایجاد امکان تبادل داده بین نرمافزارها و بانکها. ویژگیهایی چون دسترسی به دادههای تراکنشی، انتقال و پرداختهای نوین و اخیرا تعیین اعتبار چند-فاکتوره را ممکن میسازد اما نماینده امن دیگری را پشتیبانی نمیکند. | US- ایجاد شده در سال ۱۹۹۷ توسط مایکروسافت، Intuit و CheckFree. با هدفمندی US و پشتیبانی از سوی بیش از ۵۵۰۰ بانک و دلال | www.ofx.net |
۷ | خدمات تراکنشی مالی (Fin TS) | پروتکل باز موجود در نظر عموم برای رابط بانکداری و استفاده مستقیم کاربر. مواردی چون خدمات معمول بانکداری، خدمات مدیریت ثروت، امنیت، قابلیت کارکردی و انبوه سازی حسابها از موسسات مختلف را ممکن میسازد. | آلمان- ایجاد شده در سال ۱۹۹۵ و مدیریت شده توسط Deutsche Kreditwritschaft، اتحادیه بانکداران آلمانی | www.hbcizka.de |
۸ | شبکه معماری صنعت بانکداری | BIAN بانکها، شرکتهای نرمافزاری و ارائهدهندگان خدمات را گرد هم آورده تا یک استاندارد معماری سرویس-محور برای هر دو رابط درونی و خارجی توسعه دهد تا از قابلیت همکاری بین سیستمهای IT بانکهای مختلف در جهت ایجاد چشمانداز مشترک خدمات IT اطمینان حاصل کند. | موسسات مالی به این موارد محدود نیست اما تقریبا شامل AB-AMRO، ING، Rabobank، Erste، Credit Suisse، Société Générale، و گروه UniCredit با شرکایی چون مایکروسافت، IBM، SAP، ACI، Capgemini و سویفت و … | bian.org |
۹ | گروه برلین | در سال ۲۰۰۴ آغاز به کار کرد و هدف اصلی آن تحقق اهداف هیئت پرداختهای اروپایی، بانک مرکزی اروپا و کمیسیون اروپایی با در نظر داشتن SEPA با تمرکزی خاص بر چهارچوب کارتهای SEPA است. یک پژوهش عملی را که استاندارد مشترکی برای استقرار پردازش دوجانبه تراکنشی کارت بین به دست آورنده و مسئله پردازان در اروپا دارد توسعه بخشید. تعریف و حفظ استانداردها یکی از توجهات منحصربفرد جاری است. | ۲۸ شرکت کارتی از ۱۲ کشور اتحادیه اروپا. این شرکتها با هم ۱۸ بیلیون تراکنش کارتی در SEPA ارائه دادهاند. | www.berlingroup.org |
۱۰ | گروه علاقمند به پرداختهای وبی W3c | ماموریت گروه علاقمند پرداختهای وبی بخشی از فعالیتهای پرداختهای وبی است که مضمون آن ایجاد یک فروم برای مباحث فنی پرداختهای وبی به منظور شناسایی ملزومات و موارد استفاده برای خصوصیات موجود یا جدید تسهیل پرداختها برای کاربران وب(پرداخت کنندگان) و کسب و کارها (دریافت کنندگان)، و برقراری زمینه مشترک برای ارائه دهندگان خدمات پرداخت بر روی پلتفرم وب میباشد. هدف کلی این گروه شناسایی و بهبود شرایط برای درک بیشتر و وسیعتری از استفاده پرداختهای وب از طریق شناسایی نیازهای استانداردسازی به منظور افزایش همکاری بین ذینفعان و روشهای پرداخت مختلف است. | ۱۳۰ متخصص از دامنه وسیعی از موسسات، از همه نواحی جهان. | www.w3.org |
اکثر پیشروهای بالا محدوده کاملی (قانونی، عملیاتی، کارکردی و فنی) از نمونههای که در بخش پیش تشریح شد پوشش میدهند. پیشروها و بدنههای نظارت در این نمونهها متفاوتند. موقعیت پیشروها از حیث حیطه در شکل ۳ خلاصه شده است.

برخلاف پیشروهایی چون SEPA و پرداختهای آنی، که در آن بانکها رهبری استانداردسازی زیرساخت پرداختها را بر عهده داشتهاند، تاکنون صنعت تامین (تکنولوژی یا ارائه دهندگان سرویس) است که هدایت را در توسعه استانداردسازی API بر عهده دارد.
منبع: www.abe-eba.eu