14 min read

RTP (Request To Pay) yani “Ödeme Talebi” Bir Ödeme Devrimi mi?

Ödeme sistemleri alanında son on yılda bir önceki on yıla nazaran çok daha fazla ve daha büyük değişiklikler gördüğümüzü -benim gibi sektörün içinden gelen biriyseniz- söylemek sanıyorum yanlış olmaz.
RTP (Request To Pay) yani “Ödeme Talebi” Bir Ödeme Devrimi mi?

Ödeme sistemleri alanında son on yılda bir önceki on yıla nazaran çok daha fazla ve daha büyük değişiklikler gördüğümüzü -benim gibi sektörün içinden gelen biriyseniz- söylemek sanıyorum yanlış olmaz.

İnternetin, insanların finansal işlemleri nasıl yapacaklarını ve ne şekilde etkileyeceğini tahmin edebiliyorduk. Öte yandan, özellikle 2008 krizi sonrasında bankacılığa olan güvenin sarsılmasıyla beraber ve elbette teknolojinin de pozitif katkısıyla, daha önce hiç olmadığı kadar etkin ve etkili olmaya başlayan FinTech'ler, Açık Bankacılık ve AI gibi kavramların peşi sıra geleceğini öngörebiliyorduk.

Diğer taraftan, gerçek zamanlı ödemeler (real-time payments) yeni bir konu değil - esasında, ilk ödeme (Japonya, 1973) birçok ATM ağından veya banka kartından daha öncedir. Bu yıl yani 2020'nin başında en az yedi ülke tarafından 2019 yılı için 1 milyardan fazla işlemin gerçekleştirildiği bildirilmişti. İlaveten, bugüne kadar küresel olarak yaklaşık 50 milyardan fazla işlem proses edilmiş durumdadır.

Açık Bankacılık, gelişiminin erken safhalarında bulunuyor olsak da, bankaların API'nin ne olduğunu bilmediği veya herhangi bir şekilde Açık Bankacılığın söz konusu olmadığı ülkelerin var olduğunu hayal etmek bile çok zor. Ayrıca, birçok kişi tarafından çok muhafazakar bir kuruluş olarak kabul edilen Swift dahi, Eylül 2020'de tüm platformunu ve çalışma şeklini API'ler ve Açık Bankacılık ile uyumlu olacak şekilde yeniden inşa ettiğini paylaşmıştı.

Öyleyse, bir banka ne inşa etmelidir?

Cevap, belki de “Ödeme Talebi”dir (RTP: Request to Pay). Çünkü, RTP yalnızca bir bankanın yeni gelir akışları yaratmasına ve İşletme ya da KOBİ segmenti gibi gibi müşterilerine daha iyi hizmet vermesine imkan vermekle kalmaz, aynı zamanda müşterilerinin beklentilerini karşılamanın yeni yollarını bulabileceği temelleri de atmasını sağlar.

Ödeme Talebi (RTP), gerçek zamanlı ödemeler için giderek daha fazla “öldürücü uygulamalardan” (killer application) biri olarak görülmekte. Gerçek zamanlı ödeme altyapısı üzerine inşa edilen uygulamalar olarak daha fazla kullanılmakta. Peki aslında RTP nedir?

RTP (Request To Pay) ya da "Ödeme Talebi" nedir?

RTP, bir alacaklının ödeyenden belirli bir ödeme için talepte bulunduğu ve birçok senaryoyu kapsayan geniş bir terim olarak ifade edilebilir. Yaygın bir yanılgı olarak yeni bir ödeme türü değildir. En basit haliyle, ödeme yapana ödemeyi yapmak için gereken ayrıntılarla (tutar, son ödeme tarihi ve gerekli hesap ayrıntıları, vb gibi) mesaj göndermenin bir yoludur.

Daha sofistike RTP çözümleri, alacaklı ve ödeyen arasında daha yüksek düzeyde iletişim ve ikili iletişim sunmaktadır. Diğer bir deyişle, alacaklı belirli bir yanıt (response) seçebilir ve bu da daha sonra farklı bir sonucu tetikleyebilir, örneğin tam tutarın ödenmesi veya daha sonraki bir tarihte ödeme yapılması gibi. Teorik olarak, herhangi bir ödeme türüne açık bir şekilde bağlı değildir. Mesajlaşmanın gerçek zamanlı doğası nedeniyle genellikle gerçek zamanlı ödeme altyapısı üzerine inşa edilmiş olsa da, hatta günümüzde neredeyse tüm çözümler gerçek zamanlı bir ödemeyi tetiklese de, her türlü ödemeyi başlatacak şekilde tasarlanabilir.

Aşağıdaki şekil, bir örnek olarak ele alındığında, İngiltere’deki RTP çözümünün nasıl çalışacağını ve mümkün olan bazı yetenekleri göstermektedir.  İlk bakışta bu, müşteriye gönderilen geleneksel bir faturadan farklı görünmese de, hem etkileşimli hem de entegre olduğunu unutmamak lazım.

Diğer başka birçok özellik burada vurgulanabilir;

  • Alıcı, mesajına iki öge ekliyor. İlki bir ödeme referansıdır. Şu anda İngiltere ödeme sistemleri, ödeme yapanın referans olarak ödemeye 16 karaktere kadar eklemesine izin vermektedir. Daha sonra, ödeyenin banka ekstresinde gösterilerek ödeme nedenini anlamalarına olanak tanırlar. Esasında burada asıl zorluk alacaklı taraf için olmuştur.
  • Bu verilerin alacaklıya getirdiği değer küçümsenmemelidir. Alacaklının, ödeme alındıktan sonra mutabık kılınabilmesi için bir referans eklemesine olanak tanır. Çoğu işletme için, onları RTP'de satacak olan eşleştirme ve uzlaşma yeteneği olacaktır.
  • Mesaj bir ek içerebilir. Bu muhtemelen fatura olacaktır, ancak teoride herhangi bir şey olabilir. Örneğin, bir ödeme taksit planı ayarlamak için bir kredi sözleşmesi veya bir kısmi ödeme seçeneği dahi olabilir. Gerçekte, bir elektronik fatura sunma ve ödeme biçimidir. Bunlar, ödeme yapanın ödemeyi bölmesine ve ödediği faturanın bölümlerini belirtmesine izin verme konusunda daha karmaşık olma eğiliminde olduklarından, tam olarak e-fatura sayılmazlar. Diğer yandan, 2018’den beri bir eke bağlantı eklemenin mümkün olduğu Hindistan'daki UPI gibi birkaç başka sistem buna küresel olarak izin veriyor.
  • Mesajlar, Açık Bankacılık kullanılarak API üzerinden geçirilir. Kullanım bankalarla sınırlı değildir. Sonuç olarak, Fintech'lerin bu teknoloji etrafında uygulamalar yaratacağını ve muhtemelen daha geniş çözüm setlerine dahil edileceğini bekleyebiliriz. Bu, RTP çözümünün son ürün değil bir ürünler için başlangıç noktası olacağı anlamına gelmektedir. Henüz resmi olarak piyasaya sürülmemiş olsalar da, hali hazırda RTP üzerine inşa edilmiş çözümlere sahip olan Fintech'ler görülmeye başlanı. Bir örnek, Faster Payments Scheme'nin eski üst düzey yöneticilerinden bazıları tarafından kurulan Ordo'dur. Hem talebi başlangıçta gönderen hem de gönderilen faturalarla mutabık kılan Xero gibi muhasebe paketlerine doğrudan bağlanma yeteneği gibi işlevleri zaten geliştirdiler. Tek başına bu otomasyonun büyük bir tasarrufla sonuçlanması muhtemeldir.

RTP Uygulamaya Başlamalı mı? Örnekler Neler?

Dünyanın her yerinde RTP ile ilgili canlı ya da planlanmış projeler görülmektedir - her biri farklı proje seviyelerinde ve hedeflerinde olduğu için birbirinden farklı özelliklere sahiptirler. Bununla birlikte, muhtemelen iki boyutta genel olarak kategorize edilebilirler. Aşağıdaki şekil, ortaya çıkan bu farklı yaklaşımları basit bir şekilde gösteriyor. Herhangi bir yaklaşımın diğerinden daha iyi olduğu şeklinde yorumlamamakta yarar var.

Birinci boyut, işlevselliğin zenginliğidir. İngiltere sistemi, işlevsellik açısından zengin sistemlerden biridir, ancak ülke çapındaki programlarda çok daha azı sunulmaktadır. Bu birçok nedenden dolayı olabilir, ancak mesajlaşma katmanını oluşturmanın karmaşıklığı kesinlikle bunlardan biri olarak görülmektedir. Aynı şekilde, gayri resmi planlar da zengin özelliklere sahip olabilmektedir. Örneğin; dinamik QR kodlarının veya bir takip uygulamasının kullanılması ek işlevsellik sağlayabilmektedir. Fonksiyonel zenginlik eksikliği, bazı şemaların (schemes) çok az değer sunduğu anlamına gelmiyor, daha çok, pazarlama odaklı ve asgari uygulanabilir bir ürünün hedeflendiği varsayılabilir.

İkinci boyut, resmi ve gayri resmi şemalara ilişkindir. İngiltere örneğine bakıldığında, ödeme şeması koordinatörünün sıklıkla katılımcıları kullanmaya teşvik ettiği veya “teşvik ettiği” iyi tanımlanmış kurallar, roller ve standartlar vardır. Sonuçta, erişimi sağlamanın yetkilendirmekten daha iyi bir yolu olamayacağı açıktır. Bu, daha yüksek düzeyde benimseme, daha fazla rekabet yaratma ve nihayetinde kullanım avantajına sahip olmak demektir. Hindistan'daki UPI ise, çoklu kullanım durumlarını desteklemek için tasarlanmış resmi ancak zorunlu olmayan bir programın örneğidir. Henüz 2016'da başlatılan bu programla, Ağustos 2020'de aylık hacimler 1,5 milyar işlemi aşmış ve 1,3 milyar dolardan fazla üretim sağlanmıştır. Bunu kullanan birçok banka olsa da, en büyük hacmin bir kısmı Google Pay, PhonePe ve PayTM gibi Fintech'lerden gelmektedir.

Kayıt dışılık, fonksiyonel eksiklik olduğu anlamına gelmez!

Gayri resmi programların çoğu eşit derecede başarılıdır. Bu muhtemelen satış veya teslimat noktasında QR kodlarının kullanımındaki büyük artışla ilgilidir. Çin'de, taksilerin sürücünün ayrıntılarını yolcuya ileten bir QR koduna sahip olması çok yaygındır. WeChat Pay, AliPay veya Togo gibi bir uygulamada ödeme yapma talebini tetiklemektedir. Gayri resmi ve resmi şemaları bir araya getiren örnekler de vardır. Poste Italiane, artık bir SEPA Inst işlemini tetikleyen, ancak gelecek sürümde bir SEPA RTP işlemini tetikleyecek olan QR kod tabanlı bir çözüme sahiptir.

Bu örneklere dayanarak, daha az çekici olduğu ve daha az işlevsellik sunduğu için gayri resmi kapalı döngü ile birleştirmek kolay olabilir. Açık olmak gerekirse, kendi özel uygulamalarının kullanıcıları arasında ödeme başlatmak için teknolojiyi kullanan şirketleri ifade etmek için gayri resmi kullanılmaktadır. Bireysel olarak bile, WeChat Pay ve AliPay'in müşteri tabanı herhangi bir bankadan daha büyüktür - bu yüzden farkı yaratan birlikte çalışabilirliktir. Bununla birlikte, Hong Kong'da aynı şirketler, kart ağlarını bypass etmek için birçok mağazada ve satış noktasında QR kodlarını kullanıyorlar. Buradaki önemli bir fark, bu şirketlerin aynı zamanda Hong Kong gerçek zamanlı ödeme planında da ödeme hesapları tutması ve bu da onları çok açık döngü haline getirmesidir. Peki bu gayri resmi planlar neden bu kadar popüler? İster resmi ister gayri resmi olsun herhangi bir RTP şemasında başarıyı yönlendirenin RTP'nin kendisi kadar müşteri değeri ve deneyimi olduğunu söyleyebiliriz.

Farklı şirketlerin farklı kuralları, prosedürleri ve müşteri deneyimlerine sahip olduğunu vurgulamak için gayri resmi terimi kullanılmaktadır. Hong Kong örneğinde, kısmen temel ödeme sisteminin kurallarını kullanıyorlar. Bu, bu şirketlere yönelik bir eleştiri değildir; daha ziyade, bankalar için önemli bir çıkarımı vurgulamaktadır. Geleneksel bir ödeme planında, tüketicinin hakları ile ödeme sisteminin yükümlülükleri açıkça farklıdır. Giderek artan bir şekilde tüketiciler, ödemenin banka hesaplarından gelmesi nedeniyle bankalarının sorunları çözeceğini varsayabilirler. Gayri resmi programlarda olası bir büyüme ile, özellikle sorunlar ve dolandırıcılıkta olası bir artış olacaktır. Daha resmi RTP programları, dolandırıcılığı her zaman azaltmaz, ancak birçok plan bunu çözmeye çalışmıştır. Örneğin İngiltere sistemi, birçok büyük bankanın kullandığı Alacaklı Doğrulamasını kullanmaktadır.

Markalaşma, gayri resmi RTP şemalarının daha iyi göründüğü başka bir unsurdur, ancak bu sadece resmi RTP programlarının henüz başlatılmamış olması ve bu nedenle teşvik edilmesi olabilir. RTP, bazı kullanım durumları için hem kartların hem de otomatik ödemelerin yerini alacak şekilde lanse edilmektedir. Yine de ikisinin de çok güçlü ve iyi anlaşılmış markaları ve marka vaatleri var. RTP'nin eşit derecede iyi anlaşılması için çok çalışması gerekecektir. Bazı markalar bunu başardılar. Örneğin İsveç'teki Swish ve Norveç'teki Vipps gibi, öncelikle kişiden kişiye banka havalesi hizmetlerini sunuyorlar ve her iki çözüm de RTP'yi desteklemektedir. Fatura ödemesi, mobil ticaret, mağaza içi ödemeler ve uygulama içi ödemeler gibi bir dizi kullanım durumunu desteklemekteler. Bununla birlikte, hiçbirinin RTP şemaları olarak konumlandırılmadığını belirtmek gerekir, sadece belirli kullanım durumları ile uyumludurlar.

Başarılı Olmak için Temel Kurallar

Bankaların, RTP'nin ticari müşterileri üzerinde yarattığı farklı etkileri dikkate almaları gerekir. Hali hazırda gözlenen diğer ülke örneklerinden ve piyasadaki ihtiyaçtan yola çıkarak, RTP'ye global bir ilgi olduğu ve herkes için bir şeyler vaat ettiği gözlemleniyor. En iyi uygulamaların çoğu, KOBİ segmentine odaklananlardır. Bunun nedeni, KOBİ'lerin genellikle daha sınırlı seçeneklere sahip olmasıdır. Örneğin, bir otomatik ödeme işletmecisi olmanın maliyeti, daha karmaşık teknolojilere yatırımın yanı sıra süreç değişikliklerini de gerektirir. Kartları kabul etmek de aynı derecede zor olabilir. İmkansız değil, ancak alternatif bir çözümün sıcak bir şekilde karşılanacağı birçok KOBİ var. Buradaki anahtar “alternatif” kelimesidir. POS işlemlerinde veya C2B işlemlerinde kartların aracılık dışı bırakılması potansiyeli varken, RTP'nin herhangi bir ödeme türü için bir ödeme talebini tetikleyebileceğini hatırlamak önemlidir. Bu nedenle, RTP, bazı senaryolarda kart kabulünün büyümesini tetikleyebilir. Ödeme yönteminin seçimi, alacaklı türüne ve bu ödeme türünün alıcı için diğerine göre değerine bağlı olacaktır.

Bankaların unutmaması gereken önemli bir nokta, ödemenin, hem öncesinde hem de sonrasında olmak üzere, süreçte yalnızca bir adım olduğudur. Ödeme talebinin oluşturulması gerekir ve genellikle bir faturayla ilişkilidir; ve ödeme bu faturayla mutabık kılınmalıdır. KOBİ, elektronik ödeme talebi gönderebilme yeteneğinden ziyade, uçtan uca süreçte olabildiğince fazla otomasyon ve basitlikten yararlanmaktadır. Özellikle zaman ve maliyet tasarrufu, KOBİ için kritik derecede değerlidir. Para toplamaya çalışırken daha az zaman ve çaba, küçük bir işletmenin kâr hanesini önemli ölçüde etkileyebilir.

Bir KOBİ için, ödeme taleplerini doğrudan muhasebe paketlerinden toplu olarak SMS veya e-postaya gönderebilen çözümler oldukça caziptir. KOBİ daha sonra çözümleri mesajın okunup okunmadığına ilişkin içgörü kazanmak için kullanabilir; ve ardından ödemeleri gerçek zamanlı olarak otomatik şekilde mutabakatlaştırabilir. Bu çözümler daha düşük bir maliyetle gelir ve fonları alternatif ödeme yöntemlerinden daha hızlı hesaba geçirir. Ayrıca, ödemeyi taksitlere bölmek veya ödeme için ileri bir tarihi kabul etmek gibi daha gelişmiş özelliklerden bazıları, hemen ödeme yapmayanları cezbetmek için daha az zaman harcadıkları anlamına gelebilir. "Ödemeyen" değil, "ödeyemeyen" kişilere öncelik verebilmek, verimliliğe pozitif etki eder ve maliyetli gecikmiş alacakların takibi süreçlerinin azalmasına yardımcı olur.

Gerçekten en iyi RTP çözümlerinin, yalnızca istek ve ödemeden var olmayıp aynı zamanda daha fazlasını da sunduğundan emin olmak gerekir. Bu, birçok RTP şemasının bitiş noktaları değil, başlangıç ​​noktaları olduğunu göstermektedir. Ya da belki daha açık bir şekilde, sadece temel RTP şemasını işleten bankaların, daha zengin (veya diğer KOBİ iş akışlarına entegre) çözümleri kullanan bankalar kadar başarılı olma olasılığı pek olmayacaktır.

Pek çok banka, kendi pazarlarında teşvik edilen RTP'ye odaklanmaktadır. Ancak gerçekte tek bir şema olmayacaktır. Örneğin, Hollanda bankaları sahip oldukları RTP şemasını kolaylaştırmak için eşler arası mesajlaşma kullanıyor. Gelecekte, EPC uyumlu EBA RTP programına da katılmaları beklenecektir. Ayrıca, en az bir Hollanda bankası Avrupa Ödeme Girişimi'ne katılıyor.

İkinci olarak, diğer birçok RTP planının hizmet vaadini destekleyen bankalara nihayetinde güvenecek gayri resmi şemalar da vardır. Bankaların, minimum uygulanabilir bir ürünün neredeyse tam tersini, yani maksimum uygulanabilir bir ürünü sunduğundan emin olmak için RTP teknoloji altyapılarını nasıl oluşturacaklarını düşünmeleri gerekir. Gerçekte, global olarak, bankaların zaman içinde birçok farklı RTP programına doğrudan katılmaları ve dolaylı olarak daha fazlasını desteklemeleri muhtemeldir.

Bankalar Ne Yapmalı?

Dikkate alınması gereken birçok konu var. İlki doğrudan RTP ile ilgilidir. Bir banka RTP şemasına katılmalı mı ve katılıyorsa ne şekilde dahil olmalı? Gerçek zamanlı ödemelerin gelecek olduğuna ve başka birçok uygulamanın inşa edilmesi için bir araç seti olarak kullanılması gerektiğine inanılmaktadır. Dahası, bir bankanın gerçekten dijital olabilmesi ve daha müşteri odaklı çözümler sunabilmesi için kritik bir temeldir. Ayrıca, Avrupa'da Açık Bankacılık hali hazırda zorunlu olduğundan, TIPS katılımı artık herhangi bir TARGET2 bağlantılı kurum için zorunludur. Bunun iki nedeni var.

İlk olarak, RTP, bankayı yeniden konumlandıran net yeni ürün ve gelir akışları yaratabilir. Banka, ödeme hacimlerinden nasıl daha fazla gelir elde edeceği konusunda daha az düşünebilir. Bunun yerine, müşterilerinin neden ödeme alıp aldıklarına ve deneyimlerini nasıl iyileştireceklerine odaklanabilirler. Daha bütüncül bir tedarikçi haline gelmek, müşteri ilişkilerini derinleştirebilir. Ek olarak, banka potansiyel olarak ödeme akışlarına bağlı olarak ek çözümler sunabilir. Örneğin, bir müşteri taksitle ödemeyi seçerse, banka bir faktoring hizmeti sunarak işletmenin daha hızlı ancak indirimli olarak ödenmesine olanak sağlayabilir. Fiyatlandırma önemli olacaktır. Bankacılık hizmetleri için fiyatlandırma hem ülkeye hem de müşteri büyüklüğüne göre değişir, bu nedenle bu fiyatın ne olması gerektiğini belirlemenin basit bir yolu yoktur. Bunun yerine bankalar, daha geniş portföylerinde nasıl yer aldığını ve RtP'nin başka hangi gelirleri üretebileceğini düşünmelidir.

İkinci nokta muhtemelen ilk noktanın karşısındaki tarafıdır. Bazı pazarlarda, banka dışı RTP çözümleri hali hazırda mevcuttur ve işletmeleri doğrudan hedeflemektedir. Bankalar şu anda bir şey yapmazsa, fırsatlarını kaçırabilirler. Aynı zamanda, hem sundukları işlevsellik hem de müşteri deneyiminin farkında olmaları gerektiği anlamına gelir. Bankaların, bir Fintech'in sunduğu işlevsellik ve deneyimin çoğunu karşılaması veya bir Fintech'in sunamayacağı bir şeyi sunabileceği uygulamalar bulması gerekecektir. Yine de, bu ikinci yönün ne olabileceği net değildir. Bununla birlikte, ilkinde hesap paketi entegrasyonunu ve harici mesajlaşma entegrasyonunu içermesi muhtemeldir. KOBİ'lerin kararını yönlendirecek olan sadece işlevsellik değil, aynı zamanda müşteri deneyimidir.

Bu, bankaların teknoloji yaklaşımları hakkında nasıl düşünmeleri gerektiğini etkiler. Bankalar, her biri farklı olacak şekilde, doğrudan veya dolaylı olarak birçok RTP programını destekleyecektir. RTP'nin tek tek öğelerini ayırırlarsa, her şemayı ya başka şemalarda bulunan ya da şemadan bağımsız olan ek işlevsellik ile geliştirebilirler. Örneğin, RTP süreci yalnızca gerçek zamanlı bir ödemeyle değil, diğer ödeme türleriyle de sonuçlanabilir. Kartlar daha pahalı olsa da, küçük işletmeler müşterilere daha fazla seçenek sunan ve ödeme yapmalarını kolaylaştıran bir çözüme sahip olmayı tercih ederler. Burada, iyi bir kullanıcı deneyimi yolculuğu alacaklının belirli bir ödeme kanalını tanıtmasına veya yönlendirmesine ve aynı zamanda müşteriye seçim yapmasına izin vereceğinden, RTP çözümünün tasarımı anahtar olacaktır. Bunun başka avantajları da vardır - eğer bir ödeme yolu mevcut değilse, alacaklı hala başka seçeneklere sahiptir.

Bir sonraki husus, banka üzerindeki etkileri anlamaktır. Hem bankalar hem de Fintech'ler olmak üzere tüm RTP satıcılarının hedefleyeceği müşteriler olacaktır. Banka çözümü diğerleri kadar çekici değilse bu, müşteri kaybetmek anlamına gelebilir. Banka müşteriyi elinde tutsa bile gelirde değişiklikler olacaktır. Müşteriler yine de hesaplarına ödeme almak için ödeme yapacak olsalar da, tipik olarak, örneğin bir kart ödemesiyle oluşturulan ücretlerden daha düşük olacaktır.

Likidite dengesizlikleri muhtemelen daha sorunlu olabilir. Gerçek zamanlı sistemlerde, gönderilen işlem bankadan ayrıldıktan sonra reddedilme olasılığı çok düşüktür ve alıcı parayı hemen kullanmaya başlayabilir. Bunun işe yaraması için çoğu ödeme sistemi, ödemelerin başarısız olmamasını ve alıcı banka için sorunlara neden olmamasını sağlamak için tamamen finanse edilmiş, tamamen likit ödeme hesapları kullanır. Para başka bir amaçla kullanılamayacağından, herhangi bir zamanda doğru likidite seviyesini tahmin etmek de önemlidir. Çok fazla likidite, çok az olduğu kadar kötüdür. Doğrudan borçlandırmalarda, bankaların her ikisi de ne zaman ve genellikle ödemelerde daha düşük bir dengesizlik olduğunda hangi likiditenin gerekli olduğu konusunda daha fazla öngörüye sahiptir. Büyük şirketlere akan doğrudan borçlar genellikle maaşlar ve tüketicilere gönderilen emekli maaşları ile dengelenir. Tam olarak doğru olmasa da bu, gerçekleşen dengelemeyi göstermektedir. Gerçek zamanlı sistemler ayrıdır ve bu nedenle, bir işletmeye yönelik tüketici ödemelerinin akışında bu dengeye sahip olma olasılığı düşüktür. Perakende bankalar muhtemelen daha yüksek seviyelerde likiditeye ihtiyaç duyacakken, büyük KOBİ veya ticari hesabı olan bankaların daha düşük seviyelere ihtiyacı olacaktır. Bazı programlar, alıcı bankanın gönderen bankaya bir ücret ödemesi ile bunun maliyetini almaya çalışır. Açıkçası bu, yalnızca resmi şemalar gibi belirli durumlarda işe yarar.

RTP trendi yükseldikçe, bankaların altyapılarının bununla başa çıkabilmesini sağlamaları gerekecektir. Bu, kısmen gerçek zamanlı ödemelerin ve açık bankacılık yazılımının ölçeklenebilirliğidir. Ölçeklenebilirlik yalnızca toplam hacim değil, aynı zamanda en yüksek işlem ve kullanılabilirliktir. Otomatik borçlar çok öngörülebilir olsa da, perakende işlemleri (yani, satış noktasındaki RTP) değildir. Bu nedenle, çoğu program, daha hızlı ödemelerde kullanılabilirlik için çok yüksek gereksinimler getirir. Ayrıca, işlemin bir parçasını oluşturan daha fazla mesaj akışı ile bu kullanılabilirlik özellikle önemli hale gelir. RTP mesajlaşmasına dahil olma ihtimali olan API çağrılarındaki artış göz önüne alındığında, bulut sistemlere daha fazla ihtiyaç olabilir ya da altyapıya ciddi yatırımlar yapmak anlamına gelebilir.

SON SÖZ OLARAK;

Mustafa Aktaş'ın bu konuda kaleme aldığı ve Medium'da yayınlanmış bir yazısı harika bir içerik sunuyor. Üstelik RTP'nin akışının da müthiş bir kolaylıkla anlaşılmasını sağlıyor. Bahse yazıya buradan erişebilir ve içeriğinden faydalanabilirsiniz. Kalemine sağlık Mustafa Aktaş :)
Şayet yorum yapmak isterseniz buradan giriş yapabilirsiniz!