Visa EAS Server (Extended Access Service), Visa’nın kimlik doğrulama altyapısında kullanılan bir sunucudur. Özellikle Visa Secure (3-D Secure 2.x) çerçevesinde, kart sahibi doğrulama sürecini bankalar ve Visa ağı arasında güvenli biçimde yürütmek amacıyla geliştirilmiştir.

Temel Tanım

EAS Server, kartı çıkaran banka veya onun teknik servis sağlayıcısı tarafından kullanılan, EMV® 3-D Secure standartlarına uygun bir kimlik doğrulama bileşenidir.
Bu sistem, kart sahibinin çevrim içi alışverişlerde kimliğinin doğrulanmasını sağlayarak dolandırıcılık riskini azaltır. Visa’nın yönetiminde çalışabileceği gibi bankalar kendi bünyelerinde de bu sistemi barındırabilir.

EAS Server’ın Görevleri

  1. Kimlik doğrulama taleplerini yönetir.
    Online işlemler sırasında gelen 3-D Secure (AReq) isteklerini alır ve kart sahibinin kimliğini doğrulamak için gerekli adımları uygular.
  2. Visa Directory Server ile iletişim kurar.
    Kartın Visa Secure kapsamına girip girmediğini kontrol eder ve ilgili yönlendirmeleri yapar.
  3. ACS (Access Control Server) ile bağlantı kurar.
    Banka kendi ACS çözümünü kullanıyorsa, EAS Server bu çözüm ile Visa ağı arasında köprü görevi görür.
    Eğer Visa’nın yönetilen EAS-hosted ACS çözümü tercih ediliyorsa, süreç Visa tarafından uçtan uca işletilir.
  4. EMV 3-D Secure 2.x uyumluluğu sağlar.
    Dinamik risk bazlı doğrulama, token ve biyometrik doğrulama gibi gelişmiş güvenlik yöntemlerini destekler.

Mimari Konum

Basitleştirilmiş veri akışı şu şekildedir:

Kart Sahibi (Mobil Uygulama/Web)
   ↓
İşyeri (Merchant Plug-In)
   ↓
Visa Directory Server
   ↓
Visa EAS Server (Issuer Tarafı)
   ↓
Issuer (Banka)

Bu yapı, 3-D Secure işlemlerinin Visa ağı üzerinden güvenli biçimde gerçekleşmesini sağlar.

Bankalar Açısından Önemi

Kısa Özet

BaşlıkAçıklama
Tam AdıVisa Enterprise Authentication Server
RolüKart sahibi doğrulamasını yönetir
Kullanım AlanıVisa Secure (3-D Secure 2.x) işlemleri
KullanıcıIssuer bankalar ve Visa katılımcıları
AmacıDolandırıcılığı önlemek, güvenli işlem sağlamak
ModelVisa-hosted veya bankaya özel yapı
*https://www.bain.com/insights/embedded-finance/

Gömülü Finans (Embedded Finance), finansal ürün ve hizmetlerin finansal olmayan platformlara, deneyimlere veya iş süreçlerine entegre edilmesi anlamına gelir.

Başka bir ifadeyle; finansal kurumlar tarafından sunulan hizmetlerin, finansal olmayan kuruluşların ürün veya hizmet süreçlerine dahil edilmesidir.

Bu model, finansal işlemleri günlük yaşamın doğal bir parçası haline getirerek hız, kolaylık ve müşteri memnuniyeti sağlamaktadır. Özellikle e-ticaret ve mobil uygulama ekosistemlerinde kullanıcı deneyimini güçlendiren bir dönüşüm aracıdır.

BaaS ve API Entegrasyonlarının Rolü

Gömülü finansın en önemli yapı taşlarından biri BaaS (Banking as a Service) modelidir. Bu modelde, bankalar veya fintech kuruluşları, kendi API’larını (Application Programming Interface) finansal olmayan platformlara açarak onların finansal hizmetleri entegre etmesine olanak tanır.

Bu sayede bir alışveriş sitesi, seyahat uygulaması ya da oyun platformu; kullanıcılarına ödeme, kredi, sigorta veya yatırım hizmetleri sunabilir.

Türkiye’de bu yapı yasal zemine 29 Aralık 2021 tarihli “Dijital Bankaların Faaliyet Esasları ile Servis Modeli Bankacılığı Hakkında Yönetmelik” ile kavuşmuştur. BDDK tarafından düzenlenen bu yönetmelik, BaaS modelinin ülkemizdeki çerçevesini netleştirmektedir.

Gömülü Finansın Kullanım Alanları

Gömülü finans, dijital ticaretin ve müşteri deneyiminin merkezine yerleşmiştir. Günlük hayatımızda sıkça karşılaştığımız örneklerden bazıları şunlardır:

Bu örnekler, gömülü finansın finansal hizmetleri “arka planda ama her yerde” hale getirerek müşteri bağlılığını nasıl güçlendirdiğini göstermektedir.

Hizmet Kategorileri ve Pazar Büyüklüğü

Gömülü Finans sağlayıcıları sundukları hizmete göre dört ana başlıkta toplanabilir:

  1. Ödeme hizmetleri: Elektronik para kuruluşları ve ödeme şirketleri
  2. Borçlanma hizmetleri: Finansman kuruluşları veya servis bankaları
  3. Yatırım hizmetleri: Aracı kurumlar, robo-danışman platformları
  4. Sigortacılık hizmetleri: Dijital kanallardan sunulan mikro sigortalar

Küresel ölçekte, çeşitli araştırma raporlarına göre gömülü finans pazarının 2024 yılında yaklaşık 100-115 milyar USD civarında olduğu ve 2029’a kadar 200-550 milyar USD aralığına ulaşmasının beklediği görülmektedir.

Türkiye’deki Yasal Çerçeve

Gömülü Finans iş modeli, Türk hukuk sisteminde aşağıdaki temel düzenlemelerle desteklenmektedir:

Bu mevzuatlar, hizmetin kim tarafından sunulduğunun, müşteriye nasıl aktarıldığının ve sorumlulukların nasıl paylaşıldığının belirlenmesi açısından önemlidir.

Gömülü Finansın Geleceği

Gömülü Finans, finansal hizmetleri her sektörün doğal bir uzantısı haline getirerek yeni bir finansal ekosistem yaratmaktadır.

Önümüzdeki dönemde; yapay zekâ destekli ödeme akışları, otomatik kredi teklifleri, şirket içi finansal çözümler ve Agentic Commerce gibi yenilikçi yapılarla birleşerek çok daha akıllı, öngörülü ve kullanıcı odaklı hale gelecektir.

Türkiye, açık bankacılık ve fintech altyapısını hızla geliştiren ülkeler arasında yer aldığı için bu dönüşümden erken fayda sağlayabilecek bölgelerden biri olarak görülmektedir.

Sonuç

Gömülü Finans, finansal hizmetlerin finansal olmayan işletmelere BaaS ve API altyapıları üzerinden sunulmasıyla finansal katılımı ve müşteri deneyimini yeniden tanımlamaktadır.

Bu ekosistemde en kritik unsur, hizmetin kimin tarafından sağlandığının şeffaf biçimde belirtilmesi ve yasal yükümlülüklerin doğru yapılandırılmasıdır.

Gömülü Finans, yalnızca teknolojik bir yenilik değil, aynı zamanda finansal hizmetlerin demokratikleşmesi yönünde atılmış büyük bir adımdır.

Kartlı ödeme sistemlerinde son dönemin en dikkat çekici gelişmelerinden biri, temassız işlem limitlerinin artık sabit olmaktan çıkıp müşteri bazında dinamik olarak yönetilebilir hale gelmesi. Mastercard ve Visa bu konuda farklı ama birbirini tamamlayan yaklaşımlar geliştiriyor. Peki bu değişim, kart işlemlerinin bel kemiğini oluşturan ISO 8583standardına nasıl yansıyacak?

Mastercard’ın Yaklaşımı

Mastercard, Dynamic CVM Limit Management adını verdiği yapı ile temassız işlemlerde kullanılan doğrulama yöntemlerini (CVM) artık sabit limitlere bağlı olmaktan çıkarıyor. Her kartın temassız işlem limiti, kullanıcının davranışlarına, işlem geçmişine, güvenlik seviyesine ve bankanın risk politikalarına göre dinamik olarak güncellenebiliyor.

Bu sayede sistem, güvenli kullanım sergileyen kartların limitini otomatik olarak artırabiliyor veya risk tespit edildiğinde doğrulama yöntemini anında değiştirebiliyor. Bankalar açısından bakıldığında kart yenilemeye gerek kalmadan dijital ortamda limit yönetimi yapılabiliyor.
Kısacası Mastercard, kart güvenliğini artık “statik limitler” yerine “dinamik güvenlik kararları” ile yönetilen bir sürece dönüştürmüş durumda.

Peki Visa’nın Bu Konudaki Yaklaşımı Ne?

Visa, dinamik limit kavramını biraz farklı bir açıdan ele alıyor. Visa’nın önceliği, limit değerinden ziyade doğrulama sürecinin kendisini akıllı hale getirmek. “Dynamic CVM Framework” kapsamında; işlem türü, tutar, kanal ve risk profiline göre hangi doğrulama yönteminin kullanılacağı gerçek zamanlı olarak belirlenebiliyor.

Yani bir temassız işlemin PIN gerektirmemesi artık sabit bir eşik değerle değil, işlemin bağlamı ve risk analizine göre kararlaştırılıyor. Bu da hem kullanıcı için akıcı bir deneyim sağlıyor hem de kart güvenliğini koruyor.
Visa böylece sabit kurallar yerine, her işlem özelinde karar veren bir güvenlik mimarisi kurguluyor.

ISO 8583’te Değişiklik Olacak mı?

ISO 8583, kartlı işlemlerde kullanılan mesaj formatını tanımlayan uluslararası standart. Yeni teknoloji ve işleyişlere göre ISO 8583 standartları da güncellenmektedir.

Dinamik CVM Limit Management gibi sistemlerin tam anlamıyla çalışabilmesi için ISO 8583 tarafında da bazı gelişmelerin kaçınılmaz olduğu söylenebilir. Öne çıkan başlıklar şunlar:

Tam anlamıyla yeni bir ISO 8583 versiyonu beklenmiyor; ancak scheme-specific extension yapıları ve profil bazlı tanımlamalar giderek yaygınlaşacak gibi görünüyor.

Kart Sistemi Yazılımını Yönetenler Ne Yapmalı?

Bu dönüşüm, kart sistemlerini yöneten ekipler için teknik olduğu kadar stratejik bir gündem. Atılması gereken adımlar şöyle özetlenebilir:

  1. Mesaj yapısını analiz edin.
    Terminalden gelen ISO 8583 mesajlarında hangi alanların aktif kullanıldığını inceleyin. Dinamik CVM senaryoları için gereken alanlar tanımlı mı, değilse planlayın.
  2. Risk motoru ile entegrasyonu güçlendirin.
    Dinamik limit ve doğrulama kararları sadece terminalde değil, issuer host ve risk analiz katmanında verilmelidir. Gerçek zamanlı karar verebilen bir yapı kurun.
  3. Scheme dökümanlarını takip edin.
    Visa ve Mastercard bu konuda düzenli olarak teknik bültenler yayımlıyor. Yeni alanlar ve zorunlu değişiklikler genellikle bu belgelerde ilk kez duyuruluyor.
  4. Yeni işlem kanallarına hazırlanın.
    SoftPOS, mobil cüzdan veya tokenized işlemler farklı alan tanımlarına ihtiyaç duyabilir. Sistem mimarisinde bu genişlemelere yer açın.
  5. Test kapsamını genişletin.
    Limit aşımı, cihaz doğrulaması, yurt dışı işlem gibi dinamik CVM senaryolarını laboratuvar ortamında test edin. Gerçek koşullara yakın testler, canlı ortamda sürprizleri azaltır.

Sonuç

ISO 8583 standardında henüz resmi bir değişiklik ilan edilmedi. Ancak ödeme ağlarının dinamik doğrulama süreçlerine geçişi, bu dönüşümün kaçınılmaz olduğunu gösteriyor.
Kart sistemlerinin geleceği, artık sabit kurallarla değil, anlık veriye dayalı karar mekanizmalarıyla şekilleniyor.

Dolayısıyla kart sistemi yazılımlarını yönetenlerin bugünden itibaren mesaj şemalarını, risk modellerini ve terminal yapılarını bu yeni döneme göre tasarlamaya başlaması gerekiyor.

Temassız ödeme, hız ve pratiklik açısından kullanıcı deneyimini önemli ölçüde iyileştirmiştir. Ancak kart sahiplerinin en sık dile getirdiği konulardan biri, temassız işlem limitinin sabit olmasıdır. Peki, bu limit bankadan bankaya değişebilirken müşteri bazlı olarak da dinamik biçimde yönetilebilir mi?

Mevcut Durum: Sabit Limit Yaklaşımı

Türkiye’de temassız ödeme limitleri uzun yıllardır TCMB ve BKM tarafından belirlenen üst sınırlarla yönetilmektedir. Bankalar, bu sınıra kadar olan işlemleri PIN’siz (CVM’siz) olarak kabul etmektedir. 2025 yılı itibarıyla 1.500 TL temassız işlem limiti, tüm kart kullanıcıları için aynı şekilde uygulanmaktadır.

Bu yapı operasyonel açıdan basitlik sağlasa da, müşteri segmentleri (örneğin genç kullanıcılar, premium kart sahipleri veya yüksek riskli gruplar) açısından herkese aynı limitin uygulanması hem güvenlik hem de müşteri deneyimi tarafında kısıtlayıcı olmaktadır.

Müşteri Bazlı Limit Yönetimi Yaklaşımı

Müşteri bazlı temassız limit yönetimi yaklaşımında amaç, kart sahibinin özelliklerine göre dinamik bir limit belirlenmesidir.
Bu limit;

Bu modelde aynı banka içinde bir müşterinin limiti 500 TL olurken, başka bir müşterinin limiti 2.000 TL olarak tanımlanabilecektir.

Teknik ve Regülasyonel Boyut

Bu yapının hayata geçebilmesi için bazı teknik ve yasal altyapıların uygun hale gelmesi gerekmektedir.

Ancak en önemli unsur regülasyon boyutudur. Türkiye’de TCMB ve BKM tarafından belirlenen temassız limitler, ülke genelinde standart olarak uygulanmaktadır. Bankalar kendi sistemlerinde “PIN gerekli/gerekmez” kararını kısmen farklılaştırabilse de, bunu müşteri bazında dinamik şekilde yönetmek mevcut düzenlemeler çerçevesinde açık biçimde desteklenmemektedir.

Alternatif Yaklaşım: Mobil Uygulama Üzerinden Kullanıcı Kontrolü

Bazı bankalar, kullanıcılarına mobil uygulama üzerinden “Temassız özelliğini aç/kapat” veya “Temassız limitimi düşür” seçenekleri sunmaktadır.
Bu yöntem, tam anlamıyla müşteri bazlı dinamik limit yönetimi olmasa da benzer bir kişiselleştirme deneyimi sağlamaktadır.

Bu yaklaşım sayesinde:

Geleceğe Bakış: Dinamik CVM Limiti

Visa ve Mastercard’ın 2026 sonrası yol haritalarında yer alan “Dynamic CVM Limit Management” özelliği bu alanda önemli bir yenilik getirecektir.
Bu sayede:

Bu yaklaşımın, kişiselleştirilmiş bankacılık ve agentic banking modellerinin temelini oluşturacağı öngörülmektedir.

Sonuç

Bugün itibarıyla müşteri bazlı temassız limit yönetimi teknik olarak mümkün, ancak regülasyonel açıdan sınırlı bir konudur.
Ödeme sistemlerinde kişiselleştirme eğilimi her geçen yıl artmaktadır. Bu nedenle yakın gelecekte, temassız limitin de müşterinin risk, davranış ve tercihlerine göre otomatik olarak belirlenebileceği bir yapıya dönüşmesi kuvvetle muhtemeldir.

Temassız limit, artık sadece bir güvenlik parametresi değil, aynı zamanda müşteri deneyimini farklılaştıran bir rekabet unsuru haline gelecektir.

Ödeme sistemlerinde her işlem birkaç saniye içinde gerçekleşir, ancak arka planda onlarca kontrol, doğrulama ve güvenlik katmanı çalışır. Bu katmanların amacı yalnızca işlem hızını değil, aynı zamanda finansal bütünlüğü korumaktır.
Bu yazıda, provizyon (authorization) ve takas (clearing) süreçlerinde alınması gereken önlemleri, reversal mekanizmasının kritik rolünü ve sahada en sık karşılaşılan finansal kayıp senaryolarını ele alıyoruz.

Provizyon Aşamasında Risk Kontrolleri

Provizyon, kartın geçerliliğinin, bakiyesinin ve işlem yetkilerinin kontrol edildiği ilk aşamadır. Bu noktada yapılan bir hata, takas sürecinde finansal kayıplara dönüşebilir.

Temel Önlemler

Mesaj Tutarlılığı

Takas (Clearing) Sürecinde Tutarlılık

Takas süreci, provizyonu alınan işlemlerin finansal olarak hesaplara yansıtıldığı aşamadır. Burada yaşanacak bir tutarsızlık doğrudan zarar riski oluşturur.

Veri ve Muhasebe Kontrolleri

Mutabakat ve Raporlama

Reversal Mekanizması: Finansal Dengeyi Koruyan Unsur

Reversal, bir işlemin provizyon alındıktan sonra başarısız sonuçlanması ya da teknik hatalar nedeniyle tamamlanamaması durumunda, önceden ayrılan bakiyenin geri serbest bırakılması sürecidir.
Eğer reversal süreci doğru yönetilmezse, hem kart hamili hem de banka tarafında haksız bloke veya çift tahsilat gibi sorunlar yaşanabilir.

Ne Zaman Reversal Gönderilir?

Teknik Uygulama: ISO 8583 Alanları

Reversal mesajı (MTI 0400 veya 0420), orijinal işlemi referans almak zorundadır. Bunun için:

Operasyonel Önlemler

Reversal Hatalarının Tipik Sonuçları

En Çok Yaşanan Finansal Kayıp Senaryoları

Gerçek saha tecrübelerinde sık karşılaşılan finansal kayıp senaryoları genellikle üç ana kategoriye ayrılır: işlemsel hatalar, sistemsel tutarsızlıklar ve operasyonel eksiklikler.

Timeout Reversal Gönderilememesi

Duplicate Authorization (Çift Provizyon)

Reversal–Clearing Uyumsuzluğu

Amount Mismatch (Tutar Uyumsuzluğu)

Gecikmiş Reversal (Stale Reversal)

Terminal veya Network Replay

Sistemin sorunsuz çalışması için neler dikkat edilmeli?

Sonuç

Ödeme sistemlerinde finansal kayıpların önlenmesi yalnızca fraud önlemleriyle değil, teknik bütünlüğün korunmasıyla mümkündür.
Provizyon, takas ve reversal süreçleri, zincirin üç halkasıdır — biri zayıf olduğunda tüm sistem risk altına girer.
Bu nedenle reversal mekanizmasının zamanında ve doğru uygulanması, finansal güvenliğin ve müşteri memnuniyetinin temelidir.

Visa Core Rules ve Visa Product and Service Rules dokümanları, Visa ağındaki tüm kurumlar için geçerli olan temel kuralları tanımlar.

Bu kurallar, düzenli olarak güncellenir ve Visa ağına bağlı tüm üyelerin en güncel versiyona uygun hareket etmesi beklenir.

Neden Önemli?

Visa Core Rules, sadece Visa ağına üye olan kurumlar için değil, fintech şirketleri, dijital cüzdan sağlayıcıları, açık bankacılık platformları ve ödeme sistemi geliştiricileri için de stratejik önemdedir.

Kullanım Önerileri

Aşağıdaki bağlantılar üzerinden Visa’nın güncel kurallarına ulaşabilirsiniz:

Visa Core Rules and Visa Product and Service Rules (PDF):
https://usa.visa.com/dam/VCOM/download/about-visa/visa-rules-public.pdf

Visa Rules Genel Bilgilendirme Sayfası:
https://usa.visa.com/support/consumer/visa-rules.html

“Merchant Data Standards Manual” dokümanı, Visa’nın üye kurumlar (acquirer’lar ve diğer ödeme sistemleri aktörleri) için hazırlanmış, üye işyeri (merchant), ödeme kolaylaştırıcısı (payment facilitator) ve pazar yeri (marketplace) yapılarına dair sınıflama, tanımlama ve veri standardı gerekliliklerini içermektedir. 

Bu kılavuzda öne çıkan başlıklar şunlardır:

Neden Önemli?

Özetle

Bu doküman, satıcıların ödeme ağında nasıl tanımlanacağına, hangi verilerin girileceğine ve hangi kodlamaların kullanılacağına dair net bir rehber sunuyor.
Ödeme sistemleri altyapısı geliştiren firmaların bu belgeyi uygulama mimarisi, risk uyumu, data governance ve bankacılık/regülasyon ilişkileri bağlamında değerlendirmek yerinde olacaktır.

İlgili dokümana aşağıdaki linkten ulaşılabilir:
Visa – Merchant Data Standards Manual (PDF)

Ödeme sistemlerinde POS cihazları ile banka veya ödeme kuruluşu sistemleri arasında gerçekleşen her iletişim, belirli bir mesajlaşma standardı üzerinden yürür. Bu yapı, genellikle ISO 8583 standardına dayanır. Ancak her ülke, banka veya switch ağı, bu standardın kendi ihtiyaçlarına göre tanımlanmış bir versiyonunu kullanır. İşte bu versiyonlara alt protokol denir.

Türkiye’de en yaygın kullanılan POS protokol ailesi “101.x”tir. Bu yapı, zaman içinde gelişerek “101.1”, “102.1” gibi alt sürümlere ayrılmış ve EMV, QR, FAST, Visa Direct gibi yeni nesil işlem türlerini destekleyecek hale gelmiştir.

Alt Protokol Nedir?

Alt protokol, bir POS cihazının hangi mesajlaşma kurallarını ve alan yapılarını kullanarak banka sistemine işlem gönderdiğini tanımlar.
Örneğin:

Her alt protokol, belirli alan (Data Element) setlerini, PIN blok formatlarını, MAC doğrulama yöntemlerini ve hata kodlarını kendine özgü biçimde tanımlar.

Türkiye’de Yaygın Kullanılan POS Alt Protokolleri

ProtokolKapsam / Kullanım AlanıKullanıcı KurumlarÖzellikler ve Desteklenen İşlemler
101 / 101.1Klasik POS (manyetik, chip, contactless)Ziraat, Vakıf, Halk, Kuveyt Türk, birçok özel bankaISO 8583:1987 standardı temelli. EMV destekli. Field 55, 60, 61, 62 aktif. Satış, iptal, iade, batch close işlemleri.
102 / 102.1Yeni nesil POS (EMV + QR + kampanya)Özel bankalar, ödeme kuruluşları101.1’in genişletilmiş versiyonu. Field 63 üzerinden kampanya veya loyalty bilgisi taşır. QR kodlu işlemleri destekler.
103 / 103.1Mobil POS / SoftPOSFintech firmaları (Finagotech, iyzico, Paratika vb.)Mobil cihaz tabanlı. Sadece online işlem kabul eder. EMVCo L3 uyumlu. HCE tokenizasyon ve dijital kart destekli.
201 / 201.1E-Ticaret (Sanal POS)Bankalar, sanal POS geçitleri3D Secure (MPI) entegrasyonu içerir. Field 64, 126 alanlarında risk ve doğrulama verisi taşır.
301 / 301.1ATM İşlemleriBankalar, ortak ATM ağlarıCash withdrawal, balance inquiry, mini statement işlemleri. Field 22 (Entry Mode), 60 (ATM ID) aktif.
401 / 401.1QR / FAST POSTCMB FAST sistemine bağlı POS altyapılarıBKM-FAST standardına uyumlu. TR karekod, C2B işlemleri ve FAST referans ID desteği.
501 / 501.1Visa Direct / Mastercard SendUluslararası para transfer altyapılarıCross-border remittance, send/receive işlemleri. Field 125, 127.22 gibi özel alanlar içerir.
701 / 701.1Loyalty / Kampanya POSSadakat puanı ve kampanya POS altyapısıField 63’te kampanya ID, puan bakiyesi veya promo code taşır. Satış işlemlerine paralel gönderilir.

101.1 Protokolünün Özellikleri

“101.1”, Türkiye’de en yaygın kullanılan POS–Host iletişim protokolüdür.
Aşağıdaki özellikleri taşır:

Bu yapı, bankalar arası birlikte çalışabilirliği (interoperability) sağlar ve BKM’nin switch katmanında da desteklenir.

“.1” Uzantısının Anlamı

Bir protokol numarasının “.1” ile bitmesi, aynı standardın geliştirilmiş veya genişletilmiş versiyonu olduğunu gösterir.
Bu alt sürümlerde genellikle:

Yani “101.1” → 101 protokolünün EMV ve ek alanlarla genişletilmiş halidir.

Gelecek Yönelimler

Türkiye’de POS mesajlaşma yapısı hızla API tabanlı ve açık bankacılık uyumlu hale gelmektedir.
Yeni dönemde:

Bu da klasik ISO 8583’ün yanında ISO 20022 ve JSON tabanlı mesaj setlerinin yükselmesine yol açmaktadır.

Sonuç

POS alt protokolleri, ödeme sistemlerinin görünmeyen ama kritik altyapı bileşenleridir.
Bir POS cihazının hangi protokolde çalıştığını bilmek, o terminalin desteklediği işlem tiplerini, entegrasyon gereksinimlerini ve hata yönetim mantığını anlamak açısından hayati önem taşır.

Türkiye’de 101.1 hâlâ en yaygın sürüm olsa da, fintech ekosistemi hızla 401 ve 501 protokollerine evrilmektedir. Bu dönüşüm, hem yeni nesil dijital cüzdan ve FAST işlemleri hem de uluslararası para transferleri için altyapının daha esnek ve hızlı hale gelmesini sağlamaktadır.

Ödeme sistemlerinde, özellikle EMV tabanlı debit kart işlemlerinde, PIN doğrulama süreci hem güvenlik hem de sorumluluk zinciri açısından belirleyici bir adımdır.
Peki ya kart offline PIN’e kapalı, sadece online PIN’li çalışıyor ve buna rağmen POS cihazı işlemi PIN’siz olarak issuer’a gönderiyorsa?
Ve daha da önemlisi: issuer bu işlemi onaylıyorsa, sorumluluk kimdedir?

Durumun Tanımı

Senaryo şu şekilde gelişiyor:

Sonuç: Online PIN zorunlu kart, PIN’siz onaylı işlem.

EMV Perspektifinden Akış

CVM (Cardholder Verification Method) seçimi EMV Book 3’teki “CVM Decision Tree” üzerinden yürür.
Kartın CVM listesi genellikle şu öncelikte olur:

  1. Online PIN
  2. Offline PIN (varsa)
  3. No CVM

Kart, POS’a “online PIN kullan” der; ancak terminal, offline PIN counter = 0 değerini görünce CVM adımını atlar ve “no CVM” akışı seçer.
Bu durumda POS, aşağıdaki alanlarla issuer’a mesaj gönderir:

EMV TagAlanDeğerAçıklama
9F34CVM Results0x1ENo CVM performed
9F33Terminal CapabilitiesOnline PIN destekli
9F35Terminal TypeOnline-Only Terminal

Yani terminal “PIN destekliyim” diyor, fakat “PIN yapmadım” sonucunu iletiyor.
İşte tam bu noktada liability belirleniyor.

ISO 8583 Mesaj Akışı

Alan (DE)AçıklamaGönderilen DeğerNot
DE 3Processing Code000000Satış
DE 22POS Entry Mode051Chip + Online
DE 52PIN DataYokKritik eksik
DE 55EMV DataCVM=No CVM9F34: 0x1E
DE 39Response Code00Issuer onayladı

Normalde issuer, DE52 (PIN Data) alanı olmadığında RSP=55 (Incorrect PIN) veya 57 (Not permitted) dönmelidir. Ancak issuer sistemi PIN’siz işlemi onaylarsa, bu durum CVM bypass onayı anlamına gelir.

Sorumluluk Analizi

TarafDurumSorumluluk
Acquirer / POSTerminal CVM listesini yanlış değerlendiriyor. Offline PIN counter = 0 olduğunda PIN’siz gönderiyor.Terminal konfigürasyon hatası var, ancak issuer’ın işlem onayı sorumluluğu taşır.
Issuer (Kart Bankası)Online PIN zorunlu karta ait işlem, PIN’siz geliyor. Buna rağmen onaylanıyor.İşlemi onayladığı anda liability issuer’a geçer. Fraud veya chargeback durumunda issuer sorumludur.
Network (Visa / Mastercard)CVM result mismatch tespit ederse, liability issuer’a kalır.Scheme dispute süreçlerinde issuer aleyhine karar çıkar.

Kural özetle şudur:

“Who approves, owns the risk.”
Yani PIN’siz işlemi kim onaylıyorsa, sonrasında doğacak zararın sorumluluğu ondadır.

Görsel Akış: EMV & Authorization Süreci

Kart (Online PIN Required)
        │
        ▼
POS → Offline PIN Counter = 0
        │
        ▼
CVM Decision → No CVM seçildi (hatalı)
        │
        ▼
0100 → Issuer (DE52 boş, DE55 CVM=No CVM)
        │
        ▼
Issuer → Onayladı (RSP=00)
        │
        ▼
PIN’siz Onaylı İşlem → Liability = Issuer

Çözüm Önerileri

  1. POS kernel güncellemesi: Offline PIN counter = 0 olsa bile, “Online PIN required” flag’i varsa PIN ekranı gösterilmelidir.
  2. Issuer validation: DE52 (PIN Data) boş gelen işlemler mutlaka reddedilmeli veya risk bazlı analizden geçmelidir.
  3. Network monitoring: CVM mismatch olayları scheme raporlarında düzenli kontrol edilmelidir.
  4. Transaction log analizi: DE55 içindeki 9F34, 9F33, 9F35 alanları ile terminal davranışı izlenmelidir.

Sonuç

Offline PIN counter değeri sıfır olduğunda terminalin davranışı kritik önem taşır.
Ancak işlem online yetkilendirme sürecine ulaştığında nihai sorumluluk onay veren tarafta, yani issuer’da olur.
POS hatalı davranmış olabilir, ama issuer işlemi PIN’siz onayladıysa, bu kararla birlikte fraud, chargeback veya finansal kaybın riski issuer’a geçmiştir.

Genel Tanım ve İş Modeli

Partial authorization, kartta tam bakiye/limit bulunmadığında talep edilen tutarın bir kısmının onaylanmasına, kalan tutarın başka bir yöntemle ödenmesine izin verir.
Özellikle ön ödemeli, debit kartlar, yakıt istasyonları, market POS’ları, e-ticaret gibi değişken tutarlı işlemlerde kullanılabilir.

Teknik ve Sistemsel Düzenlemeler nelerdir?

a. Yetkilendirme Akışı

b. POS Terminali ve Uygulama

c. Online / E-Commerce

Slip (POS Fişi) Düzenlemeleri

a. Slip Formatında Yeni Alanlar

AlanAçıklamaÖrnek
İşlem TutarıTalep edilen toplam tutar250,00 TL
Onaylanan TutarIssuer tarafından onaylanan tutar150,00 TL
Kalan TutarMüşteri tarafından başka yöntemle ödenmesi gereken bakiye100,00 TL
Onay Kodu (DE39)“10” kodu “Kısmi Onay” olarak yazılmalı“Onay Kodu: 10 (Kısmi Onay)”
Bilgilendirme SatırıKasiyer & müşteri yönlendirmesi“Kartınızda 150 TL onaylandı. Kalan 100 TL’yi lütfen başka yöntemle ödeyiniz.”

b. Slip’te Dikkat Edilecek Konular

Takas ve Mutabakat (Clearing & Settlement)

a. ISO 8583 Mesaj Yapısı

b. Takas Dosyaları

c. Mutabakat Süreci

İşletme (Merchant) Tarafı Kullanımı

a. Standart POS Üzerinden Yönetim

Evet, işyeri sahibi (merchant) standard POS üzerinden partial authorization işlemini yönetebilir — ancak POS yazılımının bu özelliği desteklemesi gerekir.

Peki senaryo nasıldır?

  1. Kasiyer 250 TL tutarında satış yapar.
  2. POS issuer’dan 150 TL’lik kısmi onay alır (DE39=10).
  3. POS slipinde onaylanan tutar ve kalan tutar görüntülenir.
  4. POS, kasiyere “kalan 100 TL için ikinci ödeme alın” uyarısı verir.
  5. Kasiyer ikinci kart, nakit veya QR ile tahsilatı yapar.
  6. POS iki işlemi tek satış altında birleştirir ya da kasa sistemine ayrı satırla gönderir.

Önemli:

Operasyonel ve Raporlama Düzenlemeleri

Uyum & Sertifikasyon

Sonuç

Partial Authorization, acquirer için hem müşteri memnuniyetini artıran hem de tahsilat başarısını yükselten bir özelliktir.
Ancak doğru uygulanabilmesi için: