Ödeme Açığı: Altyapı Tek Başına Yeterli Değil
Kurumsal ödeme ürünleri geliştiren birçok kripto altyapı şirketi, yanlış konuda mükemmelleşiyor.
Bir blok zinciri işleminin tüm teknik detaylarına; yönlendirmeye, kesinliğe, gas optimizasyonuna ve zincir seçimine hakimler. API'leri sağlam, mutabakatları hızlı. Ancak ilk ciddi kurumsal görüşme gerçekleştiğinde, müşterinin soruları kimsenin hazırlıklı olmadığı bir noktaya odaklanıyor. Sorular teknolojiyle ilgili değil; bir şeyler ters gittiğinde ne olacağıyla ilgili.
Kim, hangi formatta ve hangi kanaldan bilgilendirilecek? Hizmet Seviyesi Anlaşması (SLA) nedir? Bir ödeme kaybolursa, yeniden deneme mantığı nedir ve bunu kim kontrol eder? İstisnai durum ödeyenin sistemine nasıl yansır? Alıcının operasyon ekibi ne görür ve bu durum hangi aksiyonu tetikler? Tırmandırma süreci nedir ve bir insan ne zaman müdahale etmelidir?
Kripto ekibi genellikle müşterinin zorluk çıkardığını veya geleneksel düşünce yapısına takılı kaldığını düşünür. Oysa müşteri teknolojiyi anlamamakla değil, teknoloji ödemelerin doğasını anlamamakla hata yapmaktadır.
Bu ayrım, bir stablecoin ödeme ürününün nasıl inşa edileceği konusunda neredeyse her şeyden daha önemlidir. İşlem katmanı önemsiz olduğu için değil, bunu bitmiş bir ürün olarak gören ekipler, ödemeleri önceliklendirip buna göre inşa eden ekiplere karşı iş kaybediyor.
Ödeme, (sadece) bir işlem değildir
Kriptoda temel düşünce birimi blok zinciri işlemidir. Adresleri, yükü, imzası, ücreti ve kesinlik durumu vardır. İşlem mempool'dan blok zincirindeki yeni bir bloğa geçtiğinde iş bitmiştir. Temiz bir başlangıç ve bitiş; teknik olarak tatmin edici.
Ödemelerde ise temel birim farklıdır. Bu bir ödeme döngüsüdür: para hareket etmeden önce başlayan ve hareket ettikten çok sonra sona eren bir süreç.
Tipik bir B2B sınır ötesi ödeme için bu döngü gerçekte şöyle görünür:
Satın alma sözleşmesi: Alıcı, satıcıdan mal veya hizmet almayı kabul eder ve fiyatları, teslimat koşullarını ve ödeme takvimini içeren resmi bir belge (genellikle standart bir satın alma siparişi) düzenler.
Fatura düzenleme ve onay: Teslimattan sonra satıcı, ödeme talebinde bulunmak için alıcıya bir fatura gönderir. Fatura; borç tutarını, ödeme koşullarını (örneğin 30 gün içinde ödenmesi gereken tutar), son ödeme tarihini ve ödeme talimatlarını (örneğin satıcının bankası ve hesap numarası) içerir. Alıcı tarafın finans departmanından biri, fatura detaylarını (teslimat durumu, fiyatlandırma, mevcut bütçe) doğrular ve ödemeyi onaylar.
Başlatma: Alıcı, ödemeyi başlatmak için kendi dahili bankacılık veya hazine yönetimi platformunu kullanır. Bu talimat; tutar, para birimi, lehtar (satıcı) bilgileri, ödeme amacı ve ödemeyi fatura veya satın alma siparişiyle ilişkilendiren referans kodları gibi yapılandırılmış veriler taşır.
Takas: Finansal kuruluşlar ödeme talimatlarını doğrular, hesap bilgilerini teyit eder ve işlemi ilgili ödeme ağı üzerinden yönlendirir. Bu aşama genellikle AML taraması, yaptırım taraması, dolandırıcılık tespiti, KYC doğrulaması ve işlem izleme gibi uyumluluk ve risk kontrollerini de içerir.
Mutabakat: Para hareket eder. Sınır ötesi bir ödeme, ödeyenin bankasından alıcının bankasına doğrudan gitmez; her biri yolculuğun bir sonraki ayağını önceden finanse eden nostro ve vostro hesaplarını tutan bir aracı zinciri üzerinden ilerler. Stablecoin ödemelerinde ise teorik olarak tüm bu süreç, aracı olmaksızın saniyeler içinde sonuçlanan tek bir zincir üstü işleme dönüşür. Kriptonun gerçekten daha iyi olduğu nokta burasıdır: daha hızlı, daha ucuz ve her zaman erişilebilir.
Mutabakat (Reconciliation): Her iki taraftaki finans departmanlarının ödemeyi ilgili yükümlülükle eşleştirmesi gerekir. Kripto entegrasyonlarının yetersiz kalabileceği nokta burasıdır. Blok zinciri işlemleri, başlangıçta minimum düzeyde yapılandırılmış meta verileri taşıyacak şekilde tasarlanmıştır. Geleneksel ödeme sistemleri ise zengin ve standartlaştırılmış referans verileri taşır; zincir üstü kesinliği deftere hazır bir onaya dönüştürmek, iyi yapıldığında tamamen görünmez olan ancak yapılmadığında felaketle sonuçlanan zahmetli bir iştir.
İstisna yönetimi: Ölçek büyüdüğünde her zaman bir şeyler ters gider. Alıcı adresi uyuşmazlıkları, mükerrer kayıt tespiti veya herhangi bir uyumluluk uyarısı, çözülmesi saatler hatta günler sürebilen Bilgi Talebi (RFI) süreçlerini tetikleyebilir. Her istisnanın deterministik bir çözüm yolu olmalıdır: geçici bir destek talebi değil, tutarlı bir şekilde yürütülebilen ve güvenilir bir şekilde denetlenebilen tanımlanmış bir operasyonel iş akışı.
İşlem, dört ve beşinci adımlardan ibarettir. Ödemeler için sistem geliştirmek, yedi adımın tamamı için geliştirmek demektir.
Geleneksel ödemeler neden bu kadar karmaşık?
Kripto ekipleri geleneksel ödeme yolculuğuyla ilk kez karşılaştıklarında genellikle şu tepkiyi verirler: Neden bu kadar karmaşık? Neden bu kadar çok aracı var? Sınır ötesi bir ödeme neden hala günler sürüyor?
Bunlar haklı sorular, ancak yapıyı sadece eski bir alışkanlık olarak görmeden önce keşfedilmeye değer yanıtları var.
Muhabir bankacılık ağı (SWIFT, nostro/vostro hesapları, aracı bankalar), sınır ötesi ödemelerin doğrudan ilişkisi olmayan taraflar arasında güven gerektirmesi nedeniyle varlığını sürdürür. Aracılar güven vekilleridir. Yavaş ve pahalıdırlar ancak değerli bir şey sunarlar: yasal sorumluluk, uyuşmazlık çözümü ve bir şeyler ters gittiğinde ödemeleri geri alma veya iptal etme yeteneği.
2023 yılında SWIFT'te kullanıma sunulan ve modern ödeme altyapısının çoğunu yöneten mesajlaşma standardı ISO 20022, ne yapmaya çalıştığını ve neyi iyileştirmeyi hedeflediğini anlayana kadar bürokratik bir aşırı mühendislik gibi görünür. Bu, ödeme verileri için ortak bir dildir (XML formatında - bu bile geleneksel ödeme dünyasının ne kadar yavaş ilerlediğini gösterir). Tokyo'da oluşturulan bir ödeme talimatının, eski MT formatında sıkça yaşandığı gibi araya bir insan girmeden Frankfurt'ta doğru şekilde işlenmesini sağlayan yapılandırılmış verileri taşımasına olanak tanır. Buradaki detaylılık, sistemin temel özelliğidir.
Ödeme hizmeti sağlayıcılarının (PSP) var olma nedeni, çoğu işletmenin her ödeme ağıyla uğraşmak istememesi (ve uğraşamaması)dır. İşletmeler; birden fazla ağı, birden fazla para birimini ve birden fazla uyumluluk yetki alanını yöneten ve arka planda ne olursa olsun tutarlı bir arayüz sunan tek bir iletişim noktası isterler. Bu orkestrasyon mantığı, stablecoin'lerden onlarca yıl öncesine dayanır. Hiçbir satıcı, kaçınabileceği bir durumsa stablecoin'lerle ayrı ayrı uğraşmak istemez.
Bu yapıların neden var olduğunu anlamak, onları olduğu gibi bırakmak için bir argüman değildir. Bu, hangi parçaların gerçekten değiştirilebilir olduğunu ve hangi parçaların, herhangi bir alternatifin farklı şekilde çözmesi gereken gerçek sorunları ele aldığını bilmemize yardımcı olur.
Dikey tuzak
Kripto altyapı şirketlerinin en sık yaptığı hata şudur.
Birden fazla zinciri, birden fazla stablecoin'i, giriş/çıkış kanallarını ve hatta kapsamlı uyumluluk araçlarını desteklemek için genel amaçlı bir stablecoin ödeme API'si geliştirirler. Entegrasyon bile oldukça basittir. Ancak daha sonra kurumsal alıcıların genel amaçlı bir altyapı istemediklerini fark ederler.
Kurumsal alıcılar, belirli sorun noktalarına yönelik çözümler ararlar. Güneydoğu Asya genelinde yüklenici ödemeleri yapan bir bordro platformu, platformun sıkı iş gücü ve vergi düzenlemelerine sahip pazarlardaki bireysel alıcılara yönelik bordro tanımlı transferleri nasıl yönettiğini bilmek ister. Aynı bölgedeki oyunculara turnuva ödüllerini dağıtan bir oyun platformu ise, sermaye kontrollerinin olduğu pazarlardaki bireylere yapılan ani ödemeleri nasıl yönettiğini öğrenmek ister. Bir kripto altyapı şirketinin her iki soruya da verdiği "bunların hepsini destekleyebiliriz" şeklindeki yanıt, alıcılar için genellikle "sorununuz üzerinde özel olarak düşünmedik" gibi duyulur.
Bu, yatay altyapı oluşturmaya karşı bir argüman değildir. Güçlü likidite ve uyumluluk katmanları diğer her şeyin ön koşuludur; zayıf bir temel üzerine güvenilir dikey yüzeyler inşa edemezsiniz. Ancak yatay altyapı, kurumsal bir alıcı için kendi bağlamlarına özgü bir şey aracılığıyla sunulana kadar görünmezdir.
Amiral gemisi bir fikri mülkiyete, rekabetçi bir devreye ve Güneydoğu Asya genelinde büyüyen bir oyuncu kitlesine sahip Çinli bir oyun şirketini düşünün. Turnuva ödül ödemeleri, birçoğunun kurumsal banka hesabı olmayan ve maç sonucundan sonraki saatler içinde fon bekleyen, düzinelerce farklı yargı bölgesindeki bireysel kazananlara gider. Uluslararası düzeyde toplanan oyun içi gelirlerin, ülkelerine geri gönderilmeden önce SAFE raporlama gerekliliklerini ve sermaye kontrollerini aşması gerekir. Birçok Güneydoğu Asya düzenleyicisi, oyunla bağlantılı ödemeleri, gelişmiş izleme yükümlülükleri olan özel bir ödeme kategorisi olarak ele alır. Bunların hiçbiri genel amaçlı bir API'nin dokümantasyonunda yer almaz, çünkü API tasarlanırken bunların hiçbiri öngörülmemiştir.
Kurumsal ödemelerde derinlik, genişlikten üstündür. Doğru uzun vadeli mimari, dikey yüzeylere sahip yatay altyapıdır: hedeflenen koridorlara ve dikeylere yönelik özel entegrasyonlar, iş akışları ve dokümantasyon içeren ortak bir temel platform. Yatay katman onu ölçeklenebilir kılar, ancak dikey katman onu satılabilir yapar. Her ikisi de gereklidir.
Gerçek karar verici olarak Ödeme Hizmeti Sağlayıcıları (PSP'ler)
Bir ödeme ürününün nasıl tasarlanması gerektiğini değiştiren daha ileri bir çıkarım daha vardır.
Bir stablecoin ödemesinin uç noktaları (gönderici ve alıcı) genellikle doğru entegrasyon hedefi değildir. Son müşteriler, ödeme yeteneğinin ERP'leri veya ödeme platformları gibi halihazırda kullandıkları yazılımlara gömülmesini isterler. Çoğu durumda, özellikle kripto ve beraberinde getirdiği iç incelemeleri içeren bir stablecoin altyapı sağlayıcısı ile yeni bir tedarikçi ilişkisi kurmanın getirdiği yükü istemezler. Mevcut tedarikçilerinin onlar için stablecoin yeteneği eklemesini isterler.
Bu, asıl satın alma karar vericisinin PSP olduğu anlamına gelir: yani şu anda son müşteriye hizmet veren ve temel platformunu yeniden inşa etmeden mevcut ürününe stablecoin raylarını eklemesi gereken işletme.
PSP'ler için inşa etmek, uç noktalar için inşa etmekten temel olarak farklı bir ürün felsefesidir. PSP'nin soruları ödeme mekaniklerinden ziyade entegrasyon mimarisi hakkındadır. Kullanıcı arayüzümüzü önemli ölçüde değiştirmeden mevcut akışımıza gömülebilir mi? Mevcut mutabakat formatımızı nasıl yönetir? Uyumluluk veri modelimizi (doğrudan kripto maruziyeti olmadığını ima eden) destekliyor mu, yoksa verileri sınırda dönüştürmemiz mi gerekecek? Hata modu neye benziyor ve istisna çözümünü kim yönetiyor?
Bordroya özel bir PSP veya pazar yeri ödeme sağlayıcısı gibi dikey odaklı PSP'ler başka bir katman daha ekler. Yatay bir stablecoin API'sinin yerel olarak desteklemediği, alana özgü uyumluluk gereksinimlerine, veri modellerine ve operasyonel iş akışlarına sahiptirler. Bu gereksinimleri anlama işini halletmiş ve bunlarla eşleşecek entegrasyon yüzeylerini oluşturmuş olan platform, fiyat konusunda rekabet etmez. Uygunluk konusunda rekabet eder.
Bunun nasıl inşa edileceği konusunda ne anlama geldiği
Ödeme döngüsü için tasarım yapın. Her özellik kararı, sadece beşinci adımda değil, yedi adımın tamamında değerlendirilmelidir. Mutabakat çıktı formatları, istisna yönetimi iş akışları, referans verilerinin korunması, mutabakat onayı yapısı: bunlar MVP'nin bir parçası olmalı, 2. aşama özellikleri olmamalıdır. Bunlar, kurumsal alıcıların bir pilot uygulama yürüttüklerinde aslında değerlendirdikleri şeylerdir. Döngünün geri kalanını müşterinin entegrasyon sorunu olarak bırakan hızlı ve ucuz bir işlem motoru, kripto ödeme tekliflerinin üretim sözleşmelerine dönüşmemesinin en yaygın nedenidir.
Yatay temeli oluşturun ve dikey olarak sunun. Stablecoin katmanı (çoklu zincir yönlendirme, likidite yönetimi, uyumluluk ilkeleri, mutabakat yürütme), dikey yüzeyleri mümkün kılan temeldir. Ancak bu iki şey arasındaki mesafe, kurumsal anlaşmaların kazanıldığı veya kaybedildiği yerdir. Bir oyun platformunun ödeme gereksinimi, bir ticaret finansmanı platformundan çok farklıdır: Sermaye kontrollerinin olduğu yargı bölgelerindeki bireylere yapılan turnuva ödemeleri, Singapur ile Hong Kong arasındaki bir kurumsal hazine transferinden farklı KYC mantığı, likidite ön finansmanı, uyumluluk veri çıktıları ve mutabakat yapıları gerektirir. Belirli gereksinimler için oluşturulan platform, özelliklerle değil, uygunlukla rekabet eder.
PSP entegrasyon mimarisi için inşa edin. En önemli arayüzler, son müşterilerin gördükleri değil, PSP'lerin müşterilerinin halihazırda güvendiği ürünü aksatmadan stablecoin yeteneğini mevcut yığınlarına gömmek için kullandıkları arayüzlerdir. Bu, kripto-yerel soyutlamalar yerine PSP veri modelleri etrafında tasarlanmış API'ler anlamına gelir. Uyumluluk veri çıktıları, PSP uyumluluk ekiplerinin daha fazla dönüştürmeye gerek kalmadan doğrudan kullanabileceği formatlarda gelmelidir. Hata kodları ve istisna durumları, inşa etmeleri gerekecek yenileriyle değil, PSP'lerin halihazırda sahip oldukları operasyonel iş akışlarıyla eşleşmelidir. Dikey odaklı bir PSP, bir stablecoin altyapı ortağını değerlendirdiğinde, operasyonlarına uyan bir entegrasyon ister.
Uyum verilerini bir yan ürün olarak değil, bir ürün çıktısı olarak ele alın. Platformdan akan veriler; Ödeme Hizmeti Sağlayıcısı (ÖHS) uyum ekipleri, bankacılık ortakları ve düzenleyici kurumlar tarafından görülecektir. Eğer bu veriler yapılandırılmamış, eksik veya kullanılabilir hale gelmesi için dönüştürülmesi gerekiyorsa, bu durum platform ile canlıya geçiş arasında kalıcı bir entegrasyon sorunu yaratır. Her uyum çıktısı, API'nin kendisiyle aynı özenle tasarlanmalıdır.
Stablecoin altyapıları gereklidir ancak yeterli değildir. Hiçbir ciddi kurumsal alıcı, bu altyapıya sahip olmayan bir platformu değerlendirmeye almaz. Ancak anlaşmaları sonuçlandıran şey, işlemin etrafını saran her şeydir: veri yapıları, entegrasyon yüzeyleri, istisna iş akışları, uyum çıktıları ve alıcıya onların özel sorunlarını anladığınızı ve çözümünü halihazırda inşa ettiğinizi gösteren sektörel derinlik.
"Altyapı yeterli değildir" ifadesinin pratikteki anlamı budur. İşlem katmanı önemlidir, ancak ödemeleri ilk önce anlayan ve tüm döngüyü buna göre inşa eden ekipler kazanacaktır. Ödeme için inşa edin, işlem zaten kendiliğinden hallolacaktır.
.png){kind=spacer}
