KYB testi, bir platformun işletme müşterilerini kabul ederken kurduğu doğrulama akışının denenmesidir. Bu yazıda KYB’nin kişi doğrulamasından hangi noktalarda ayrıldığını, hangi bilgilerin istendiğini, durum geçişlerinin nasıl kurgulandığını ve bu akışın deneme ortamında nasıl sınandığını bulacaksınız.
KYB neyi doğrular?
KYB, bir platformun karşısındaki tarafın bir kişi değil bir işletme olduğu durumda yapılan doğrulamadır. Kişi doğrulamasında soru “bu kişi gerçekten kim” iken, işletme doğrulamasında soru “bu işletme gerçekten var mı, kimler tarafından kontrol ediliyor ve hangi işi yapmaya yetkili” sorusudur.
Bu fark, doğrulamanın kapsamını genişletir. Bir işletmenin varlığını göstermek için tescil kaydı gerekir; o işletmeyi yöneten ve kontrol eden kişileri göstermek için ortaklık bilgisi gerekir; hangi faaliyeti yürütebileceğini göstermek için ise faaliyet konusu ve gerekiyorsa özel izinler gerekir. Bu katmanların her biri ayrı bir kontrol gerektirir.
KYB’nin karmaşıklığı tam olarak buradan gelir: işletme, kişilerden oluşan bir ağdır. Bir işletmenin ortakları başka bir işletme olabilir, o işletmenin de kendi ortakları olabilir. Bu zincir, doğrulamanın derinliğini belirler.
Hangi bilgiler ve belgeler istenir?
İstenen bilgiler ülkeden ülkeye ve iş modeline göre değişse de ortak bir çekirdek vardır.
- Tescil bilgisi: İşletmenin resmî kayıt kurumundaki kaydını gösteren bilgi ya da belge.
- Vergi bilgisi: Vergi numarası veya varsa katma değer vergisi numarası.
- Adres bilgisi: Kayıtlı merkez adresi ve gerekiyorsa bu adresi gösteren bir belge.
- Kontrol bilgisi: İşletmeyi nihai olarak kontrol eden kişilere ilişkin bilgi. Bu kavram, kara para aklamayla mücadele düzenlemelerinde yerleşik bir kavramdır.
- Faaliyet bilgisi: İşletmenin ne iş yaptığı ve faaliyeti için özel bir izin gerekiyorsa bunun varlığı.
- Temsil bilgisi: Platform adına işlem yapmaya yetkili kişi ve bu yetkinin dayanağı.
Bu listeyi bir kontrol listesi olarak kullanmak, akışın eksik tasarlanmasını engeller. Ancak asıl iş, bu bilgilerin hangi sırayla istendiğini ve eksik geldiğinde ne olacağını doğru kurmaktır.
Durum akışı nasıl kurgulanır?
Bir KYB akışı, tek bir “onaylandı” veya “reddedildi” sonucundan oluşmaz; ara durumları olan bir akıştır. En az beş durum gerekir: başvuru henüz gönderilmedi, inceleme sürüyor, onaylandı, reddedildi ve ek inceleme bekliyor.
Bu durumların her biri farklı bir davranış gerektirir. Başvuru gönderilmediyse kullanıcı eksik alanları tamamlayabilir. İnceleme sürüyorsa kullanıcıya beklemesi gerektiği anlatılır ve yeni bilgi istenmez. Onaylandıysa hesap açılır. Reddedildiyse sebep gösterilir ve düzeltilebilir bir eksikse yeniden başvuru yolu açılır. Ek inceleme bekliyorsa süreç insan değerlendirmesine devredilmiştir ve bu durum kullanıcıya açıkça söylenir.
Bu akışın en kritik parçası, reddedilme sebebinin taşınmasıdır. Sebep tek bir genel metin olursa, kullanıcı neyi düzelteceğini bilemez ve aynı eksikle yeniden başvurur. Sebep, düzeltilebilir ve düzeltilemez olarak ayrılmalıdır: belgenin okunaksız olması düzeltilebilir, işletmenin faaliyetinin platformun kabul ettiği kapsamda olmaması ise düzeltilemez.
Bu akış deneme ortamında nasıl sınanır?
Deneme ortamının amacı, akışın bütün dallarını gerçek bir işletmenin verisini kullanmadan çalıştırmaktır. Bunun için her duruma karşılık gelen ayrı bir kurgusal kayıt gerekir: eksiksiz bir kayıt, bir belgesi eksik bir kayıt, belgesi okunaksız bir kayıt ve kapsam dışı bir faaliyet taşıyan bir kayıt.
Bu kayıtlar gerçek bir işletmeye benzememelidir. Unvanın yapay seçilmesi, adresin örnek bir adres olması ve numaraların hiçbir resmî kayda karşılık gelmemesi gerekir. Böylece test sırasında hiçbir gerçek işletmenin bilgisi sisteme girmez ve üretilen ekran görüntüleri paylaşılabilir olur.
Deneme ortamı ile üretim ortamı ayrı tutulmalıdır. En sık yapılan hata, testleri kolaylaştırmak için üretim ortamındaki doğrulama adımlarını geçici olarak devre dışı bırakmaktır. Bu, testin kendisini anlamsız kılar; çünkü sınanmak istenen şey tam olarak o adımlardır.
Sınır nerede başlar?
Bu akışla ilgili en önemli sınır şudur: kurgusal bir işletme kaydı, gerçek bir platformda hesap açmak, ödeme altyapısına erişmek veya bir işletmeyi temsil etmek için kullanılamaz. Doğrulanmış görünen bir kayıt üretmek, doğrulamanın kendisini atlatmak anlamına gelir ve bunun yazılım testiyle hiçbir ilgisi yoktur.
Sınırın pratikteki karşılığı şudur: testler yalnızca kendi deneme ortamınızda çalışır, hiçbir üçüncü tarafın sistemine kurgusal bir kayıt gönderilmez ve akışın herhangi bir adımı test kolaylığı için kapatılmaz. Ayrıntılar için sanal şirket verisinin sınırları yazısına bakabilirsiniz.
Geliştiriciler için: durum makinesi, sebep kodu ve ortam ayrımı
KYB akışını tasarlarken ilk karar, durumların ve geçişlerin açıkça tanımlanmasıdır. Akış, serbestçe değişen bir metin alanı değil, tanımlı geçişleri olan bir durum makinesi olarak kurulmalıdır. Hangi durumdan hangi duruma geçilebileceği, geçişi kimin tetikleyebileceği ve geçişin geri alınıp alınamayacağı yazılı olmalıdır. Tanımsız bir geçişe izin vermek, kayıtların anlaşılmaz durumlarda kalmasına yol açar.
İkinci karar, sebep kodlarının yapısıdır. Her ret, bir sebep koduna bağlanmalı ve bu kod kullanıcıya gösterilen metne eşlenmelidir. Kodlar en az iki gruba ayrılmalıdır: kullanıcının düzeltebilecekleri ve düzeltemeyecekleri. Düzeltilebilir bir sebeple reddedilen başvuruda yeniden gönderim yolu açık olmalı; düzeltilemez bir sebep için aynı yolu açık tutmak, kullanıcıyı boşuna döngüde tutar.
Üçüncü karar, belge alanlarının nasıl saklanacağıdır. Yüklenen belgelerin türü, boyutu, yüklendiği zaman ve varsa geçerlilik süresi ayrı ayrı tutulmalıdır. Geçerlilik süresi olan belgeler için, sürenin dolmasına yakın bir uyarı üretmek, akışın sonradan beklenmedik biçimde tıkanmasını engeller. Belgelere erişim yetkisi ise role bağlı olmalı; herkesin görebildiği bir belge deposu, denetim açısından savunulabilir değildir.
Dördüncü karar, durum ile deneme ortamı ilişkisidir. Deneme ortamında akış bütün dallarıyla çalışabilmeli, ancak bu ancak ayrı bir veri deposu ve ayrı bir yapılandırma ile yapılmalıdır. Üretim ortamındaki bir kaydı geçici olarak “onaylandı” durumuna çekmek, en tehlikeli kısa yoludur; çünkü o kayıt üretimde gerçek bir hesap açar.
Beşinci karar, denetim izidir. Her durum geçişi, geçişi yapan kullanıcı, zaman ve varsa sebep kodu ile birlikte saklanmalıdır. Bu iz olmadan, sonradan “bu başvuru neden reddedildi” sorusu cevaplanamaz. İz tutulurken belge içerikleri değil, belgeye ilişkin üst veriler kaydedilmelidir.
Son olarak, test kümesini hazır bir üretim aracıyla kurun ve sabitleyin. Böylece aynı kayıtla aynı dal her zaman yeniden üretilebilir; kurgusal kayıtları elle uydurmak, dallar arasındaki farkları zamanla belirsizleştirir. Bu kayıtları üretmek için test şirket verisi üreticisinde ülke seçip kayıt üretebilirsiniz.
Sonraki adımlar
İlk adım, akışınızdaki durumları ve geçişleri yazılı hâle getirmek ve her durumun kullanıcıya ne söylediğini netleştirmektir. İkinci adım, her ret sebebinin düzeltilebilir mi yoksa düzeltilemez mi olduğunu işaretlemek ve yeniden başvuru yolunu yalnızca düzeltilebilir sebepler için açmaktır.
Akışın adres ve fatura tarafı için fatura formu testi yazısına, numaraların doğrulanması için vergi numarası doğrulama kuralları yazısına bakabilirsiniz.
Bu içerik yalnızca yazılım geliştirme ve test bakış açısıyla yazılmıştır. Anlatılan akışlar kurgusal işletme kayıtlarıyla kendi deneme ortamınızda denenmek içindir; gerçek bir başvuruda doğrulama adımlarını atlamak veya bir işletmeyi temsil etmek için kullanılamaz.