Forex brokerleri, hiç durmayan bir piyasada faaliyet gösterir. Yatırımcılar hesaplarına 7/24 erişim, anlık para yatırma ve kesintisiz emir iletimi bekler. Bir şey bozulduğunda — bir sunucu çöker, bir ödeme sağlayıcısı yanıt vermeyi durdurur, bir veritabanı bozulur — saat hemen işlemeye başlar. Her bir dakikalık kesinti para kaybettirir, güveni aşındırır ve yatırımcıları hâlâ çevrimiçi olan rakiplerine iter.
Yine de çoğu küçük ve orta ölçekli brokerin resmi bir felaket kurtarma planı yoktur. Barındırma sağlayıcısının çalışma süresi garantisine, CRM satıcısının yedeklerine güvenirler ve hiçbir şeyin tamamen yıkıcı olmayacağı varsayımına dayanırlar. Bu makale, brokerleri gerçekten çevrimdışı bırakan senaryoları, nasıl ve ne kadar hızlı kurtulacağınızı belirleyen altyapı kararlarını ve planlama sürecinin krizi iş bitirici bir olaya değil yönetilebilir bir aksaklığa nasıl dönüştürdüğünü ele alır.
Brokerler Neden Özellikle Daha Fazla Savunmasızdır?
Tipik bir forex brokeri, birbirine bağlı karmaşık bir sistem yığını çalıştırır: bir veya daha fazla işlem platformu (MT4, MT5, cTrader, DXtrade), müşteri verisi ve uyumluluk kayıtlarını içeren bir CRM, birden fazla ödeme geçidi, KYC doğrulama hizmetleri, e-posta ve iletişim araçları ve müşteriye dönük bir portal. Bu bileşenlerden herhangi birindeki bir arıza diğerlerine de zincirleme şekilde yayılabilir.
Forex’in 24/7 doğası bunu daha da kötüleştirir: Eğer işlem platformu köprüsü kesilirse müşteriler işlem yapamaz. Eğer CRM veritabanı erişilemez hale gelirse back office para çekme işlemlerini işleyemez veya yeni hesapları doğrulamaz. Eğer bir PSP entegrasyonu bozulursa yatırımlar akışı durur. Bunlar varsayımsal senaryolar değil; sektör genelinde düzenli olarak yaşanır ve bunların üstesinden gelen brokerler, bunlar için önceden plan yapmış olanlardır.
Brokerleri Gerçekten Çevrimdışı Bırakan Tehditler
Bir felaket kurtarma planı oluşturmadan önce, neye karşı kendinizi savunduğunuzu anlamak yardımcı olur. Tehditler birkaç kategoriye ayrılır.
Donanım ve altyapı arızaları en yaygın olanlardır. Bir sunucu çöker, bir disk arızalanır, bir veri merkezinde elektrik kesintisi olur. Eğer işlem platformunuz veya CRM’iniz yedekliliği olmayan tek bir fiziksel sunucuda çalışıyorsa, tek bir donanım arızası tüm operasyonunuzu çevrimdışı bırakabilir. Bulut barındırma bu riski azaltır ama ortadan kaldırmaz — hatta AWS ve Azure bile bölgesel kesintiler yaşayabilir.
Siber saldırılar giderek artan bir endişe kaynağıdır. DDoS saldırıları forex brokerlerine özellikle sık yöneltilir; çünkü saldırganlar işin zamana duyarlı olduğunu bilir ve operatörlerin sorunu ortadan kaldırmak için ödeme yapma ihtimali bulunur. Fidye yazılımı (ransomware) da diğer bir tırmanan tehdittir; özellikle KYC belgeleri dahil olmak üzere hassas müşteri verilerini saklayan brokerler için. Sağlam veri güvenliği temeli ilk savunma hattıdır; ancak bu, savunmalar başarısız olduğunda devreye girecek bir kurtarma planıyla birlikte ele alınmalıdır.
Üçüncü taraf hizmet kesintileri; harici sağlayıcılara bağlı olan brokerleri etkiler. Bir ödeme geçidi kapanır, bir KYC doğrulama API’si yanıt vermeyi durdurur veya bir işlem platformu sağlayıcısında sunucu sorunları çıkar. Bunları kontrol edemezsiniz ama bunlar için plan yapabilirsiniz. Tüm yatırımlar için tek bir PSP’ye güvenen brokerler, tek bir kesintiye karşı tamamen gelir dondurma riskini tek adımda taşır; bunun bir nedeni de birden fazla ödeme geçidi üzerinden çeşitlendirme yapmanın yalnızca bir kolaylık değil, operasyonel bir zorunluluk olmasıdır.
İnsan hatası, çoğu operatörün kabul etmek istediğinden daha fazla kesintinin nedenidir. Bir veritabanı taşıma (migration) betiği, staging yerine production üzerinde çalıştırılır. Bir güvenlik duvarı kuralı değişikliği tüm gelen trafiği engeller. Birisi işlem takvimini kontrol etmeyi unuttuğu için sunucu yoğun saatlerde yeniden başlatılır. Bunlar doğru erişim kontrolleri ve değişiklik yönetimi prosedürleriyle önlenebilir; ancak yine de kurtarma planının bir parçası olarak ele alınmaları gerekir.
RTO ve RPO: Planınızı Belirleyen İki Sayı
Her felaket kurtarma planı iki ölçüm etrafında kurgulanır: Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO).
- RTO; etki kabul edilemez hale gelmeden önce işinizin çevrimdışı kalabileceği maksimum süreyi ifade eder. Bir forex brokeri için bu genellikle dakikalar ile düşük tek haneli saatler aralığında ölçülür. Londra seansı sırasında işlem platformunuz 4 saat boyunca kapalı kalırsa, yalnızca o seans için değil kalıcı olarak da yatırımcı kaybedersiniz.
- RPO; kaybetmeyi göze alabileceğiniz maksimum veri miktarıdır. Son veritabanı yedeklemeniz 24 saat önceyse ve sunucu şimdi arızalanırsa; müşteri kayıtlarının, yatırımların, para çekme taleplerinin ve işlem hesap değişikliklerinin tamamını bir gün boyunca kaybedersiniz. Çoğu broker için RPO’nun bir saatten fazla olması zaten bir uyumluluk riskidir — KYC onaylarını, finansal işlemleri veya IB komisyonu hesaplarını yeniden oluşturamayabilirsiniz.
Bu iki sayıdan sonra alınacak tüm altyapı kararları şekillenir. 15 dakikalık RTO ve 5 dakikalık RPO’ya ihtiyaç duyan bir broker; gerçek zamanlı veritabanı replikasyonu, otomatik failover ve önceden yapılandırılmış yedek sistemlere ihtiyaç duyar. 4 saatlik RTO ve 1 saatlik RPO’ya tolerans gösterebilen bir broker; planlı snapshot’lar ve manuel failover prosedürlerini kullanabilir. Bu iki yaklaşım arasındaki maliyet farkı ciddi olduğundan, ilk adım işletmenizin gerçekte neye ihtiyacı olduğunu konusunda gerçekçi olmaktır.
Kurtarma İçin Altyapı Oluşturma
RTO ve RPO’nuzu tanımladıktan sonra altyapı gereksinimleri mantıksal olarak ortaya çıkar.
Veritabanı replikasyonu temel unsurdur. Her bir müşteri kaydını, her bir işlemi, her uyumluluk belgesini ve her IB ilişkisini tutan CRM veritabanınızın; neredeyse gerçek zamanlı olarak en az bir ikincil konuma replikasyonunun yapılması gerekir. Çoğu modern veritabanı motoru senkron veya asenkron replikasyonu destekler. Senkron replikasyon (her yazmanın, kabul edilmeden önce hem ana hem de replika üzerinde onaylanması) size RPO’yu sıfır verir ama gecikme (latency) ekler. Asenkron replikasyon daha hızlıdır ancak küçük bir olası veri kaybı penceresi doğurur.
Coğrafi yedeklilik, yedekleme sistemlerinizin fiziksel olarak ana sistemlerinizden farklı bir konumda bulunması anlamına gelir. Eğer brokeriniz Londra’daki tek bir veri merkezinden çalışıyor ve o veri merkezinde elektrik kesintisi yaşanıyorsa, aynı binadaki bir replika hiçbir işe yaramaz. Frankfurt ya da Amsterdam’daki bir replika sizi çalışır halde tutar. Bu, her kritik bileşen için geçerlidir: CRM, müşteri portalı, KYC belgeleri için dosya depolama ve işlem platformu köprüsü altyapısı.
Otomatik failover, 15 dakikalık bir RTO ile 4 saatlik olanı ayıran şeydir. Ana veritabanı sunucusu arızalanırsa ve birinin yedek sunucuyu uyandırması, yedek sunucuya giriş yapması, replikanın ana rolüne yükseltilmesi (promote), DNS’in güncellenmesi ve servislerin yeniden başlatılması gerekiyorsa bu saatler sürer. Eğer bir yük dengeleyici veya veritabanı proxy’si trafiği sağlıklı replika’ya otomatik olarak yönlendiriyorsa bu dakikalar sürer. Otomasyonun düzenli olarak test edilmesi gerekir — teoride çalışan ama pratikte hiç tetiklenmemiş bir failover aslında hiç failover değildir.
Yedekleme stratejisi salt veritabanı çoğaltımının ötesine geçer. Ransomware’a veya yanlışlıkla silmeye karşı korunmak için ayrıca periyodik olarak tam yedekler, ayrı bir konumda (tercihen farklı bir bulut sağlayıcı veya çevrimdışı depolama) saklanmalıdır. Çoğu broker için günlük tam yedekler ve saatlik artımlı yedekler makul bir başlangıçtır. Bu yedekler şifrelenmeli, düzenli bir program dahilinde geri yüklenebilirlik açısından test edilmeli ve uyumluluk gereksinimlerinize göre saklanmalıdır.
Üçüncü Taraf Arızalarını Planlamak
Kırılan her şeyin kontrolü sizde değildir. Afet kurtarma planınız, bağımlı olduğunuz hizmetlerde meydana gelebilecek arızaları da hesaba katmalıdır.
Ödeme işleme tarafında cevap yedekliliktir. Tüm para yatırma yöntemleri için asla tek bir PSP’ye güvenmeyin. Birincil kart işlemciniz devre dışı kalırsa, ikincil bir işlemci devralmaya hazır olmalı — ideal olarak müşterilerin geçişi fark etmemesi için otomatik yönlendirmeyle. Aynısı kripto ödeme sağlayıcıları ve havale/eft aracıları için de geçerlidir. Sizin CRM dağıtımınız; kod değişikliği yapmadan etkinleştirilebilen veya devre dışı bırakılabilen birden fazla PSP entegrasyonunu desteklemelidir.
Ticaret platformu kesintileri için (MT4/MT5 sunucu sorunları, cTrader kullanılamazlığı) seçenekler daha sınırlıdır; çünkü genellikle farklı bir sağlayıcı üzerinde yedek bir MetaTrader sunucusu çalıştıramazsınız. Yapabileceğiniz şey, net bir iletişim planınızın olması, platform sağlayıcınızla dokümante edilmiş yükseltme (eskalasyon) yolları ve yanıt sürelerini tanımlayan SLA’lar oluşturmaktır. Platform sağlayıcılarını değerlendirirken, imza atmadan önce onların kendi afet kurtarma altyapılarını sorun.
KYC ve doğrulama hizmetleri için en az iki sağlayıcıyla entegrasyonları sürdürün. Birincil kimlik doğrulama API’niz devre dışı kalırsa, yedek (fallback) önceden yapılandırılmış ve test edilmiş olmalı; kesinti sırasında ekibinizin kurulumu yetiştirmeye çalıştığı bir şey olmamalıdır.
İletişim Planı
Teknik kurtarma işin yarısıdır. Diğer yarısı, neler olduğunun doğru kişilere hızlıca bildirilmesidir.
İletişim planınız üç kitleyi kapsamalıdır: müşteriler, dahili ekip ve iş ortakları.
Müşteriler için en olası senaryolara önceden şablonlar hazırlayın: ticaret platformu kesintisi, para yatırma işlemi gecikmeleri, portalın kullanılamaması ve planlanmış bakım. Bu şablonlar e-posta, SMS ve müşterinizin istemci portalı bildirim sistemi üzerinden dağıtıma hazır olmalıdır. Gerçek bir kesinti sırasında yapabileceğiniz en kötü şey sessiz kalmaktır — yatırımcılar en kötüsünü varsayar ve forumlarda ile sosyal medyada paylaşmaya başlar.
Dahili ekibiniz için bir eskalasyon matrisi tanımlayın. CRM 3 AM’de düştüğünde ilk kimi arıyorsunuz? Failover’u tetikleme yetkisi kimde? Müşterilerle kim iletişim kuruyor? Bu roller önceden atanmalı; her rol için yedek personel bulunmalıdır. Paylaşılan bir dokümanda yaşayan bir runbook, kesintiye giren aynı sunucuda barındırılıyorsa işe yaramaz — erişilebilirliği bağımsız bir yerde bir kopyasını saklayın.
İş ortakları — IB’ler, ödeme sağlayıcıları, likidite sağlayıcıları — operasyonlarını etkileyen kesintiler hakkında bilgilendirilmelidir. Yönlendirme bağlantıları bozulmuş IB’lerin, trader’larından duymadan önce sizden duyması gerekir. Ödeme sağlayıcılarının, uzlaşma/rekonsilasyon sorunlarını izleyebilmeleri için yedek bir işlemciye geçtiğinizi bilmesi gerekir.
Planı Test Etmek
Test edilmemiş bir afet kurtarma planı bir dokümandır; plan değildir. Düzenli testler, bunu ekibinizin baskı altında gerçekten uygulayabileceği bir şeye dönüştürür.
Masa başı (tabletop) çalışmaları testin en basit şeklidir. Ekibinizi toplayın, bir senaryo sunun (“Londra saatiyle 10:00’da birincil veritabanı sunucusu hemen çöktü”) ve yanıtın her adımını birlikte gözden geçirin. Kim ne yapıyor? Hangi sırayla? Yedek sistemler için erişim kimlik bilgileri nerede? Her adım ne kadar sürüyor? Bu tür çalışmalar, geriye dönüp bakınca bariz görünen ama kimsenin kâğıt üzerinde fark etmediği boşlukları tutarlı şekilde ortaya çıkarır.
Failover denemeleri daha da ileri gider — yedek sisteme gerçekten failover’u tetikler, her şeyin çalıştığını doğrular ve ardından birincil sisteme geri dönersiniz (fail back). En azından çeyreklik yapın; mümkünse aylık yapın. Sürecin ne kadar sürdüğünü ve sonucun hedeflediğiniz RTO ve RPO değerleriyle uyumlu olup olmadığını takip edin. Hedef RTO’nuz 30 dakika ise ama son denemeniz 90 dakika sürdüyse, yatırımı nereye yapacağınızı bilirsiniz.
Yedek geri yükleme testleri, yedeklerinizin gerçekten kullanılabilir olduğunu doğrular. En az çeyrekte bir kez bir yedek alın ve bunu ayrı bir ortama geri yükleyin. Müşteri verilerinin eksiksiz olduğunu, KYC belgelerinin erişilebilir olduğunu, ticaret hesabı eşleştirmelerinin doğru olduğunu ve IB yapıların tamam olduğunu doğrulayın. Geri yüklenemeyen bir yedek yedek değildir.
Uyumluluk (Compliance) Hususları
Mevzuat ortamınıza bağlı olarak afet kurtarma opsiyonel olmayabilir — bir lisanslama gerekliliği olabilir.
CySEC, FCA, ASIC veya diğer otoriteler kapsamında düzenlenen broker’lar genellikle iş sürekliliği planlarını sürdürmeleri, veri kurtarma kabiliyetlerini kanıtlamaları ve önemli kesintileri düzenleyicilerine raporlamaları beklenir. Broker’ınız daha hafif bir düzenleyici ortamda faaliyet gösterse bile, dokümante edilmiş ve test edilmiş bir DR planı, sizinle çalışmadan önce gerekli özeni (due diligence) yapan potansiyel müşteriler ve iş ortakları için bir güven sinyalidir.
Veri saklama gereksinimleri de afet kurtarmayla kesişir. Bir düzenleyici, müşteri kayıtlarını 7 yıl boyunca saklamanızı isterse, yedekleme ve arşivleme stratejiniz verinin bu süre boyunca erişilebilir ve geri alınabilir kalmasını garanti etmelidir. Bu da yedekleme medya rotasyonu, bütünlük kontrolleri ve hangi verilerin nerede saklandığına dair net dokümantasyon anlamına gelir.
Asgari Uygulanabilir DR Planı Ne Gibi Görünür?
Her broker’ın çok bölgeli, aktif-aktif ve sıfır kesintili failover içeren bir kurulumuna ihtiyacı yoktur. Bu ciddi para ve mühendislik kaynağı gerektirir. Ancak boyutu ne olursa olsun her broker’ın şunları yapması gerekir:
Coğrafi olarak ayrı bir konumda saklanan, şifrelenmiş otomatik günlük veritabanı yedekleri ve aylık geri yükleme testleri. En az iki PSP entegrasyonu aktif ve test edilmiş olmalı; böylece birisi devre dışı kalırsa yatırmalar devam edebilmelidir. Dokümante edilmiş bir eskalasyon matrisi — kimin aranacağı, hangi sırayla, güncel telefon numaralarıyla (e-postalar değil — e-posta da çalışmayabilir). En olası üç kesinti senaryosu için önceden yazılmış müşteri iletişim şablonları. Her kritik sistem için bir runbook (CRM, ticaret platformu köprüsü, müşteri portalı) — manuel yeniden başlatma, failover ve geri alma (rollback) prosedürlerini kapsayan. En az bir başarısızlık senaryosunu uçtan uca inceleyen çeyreklik masa başı egzersizler.
Bu, altı haneli bir altyapı yatırımı gerektirmez. Zaman, dokümantasyon ve düzenli olarak test etme disiplinini gerektirir.
Sonuç
Afet kurtarma, çoğu broker operatörünün bir sorun çıkana kadar düşünmediği bir şeydir. O ana gelindiğinde plan yapmak için çok geç olur — tepki veriyor, improvize ediyor ve hasarın kontrol altında tutulmasını umuyorsunuz. Kesintiler, siber saldırılar ve sağlayıcı arızalarıyla daha iyi başa çıkan broker’lar; önceden ne yapacaklarını belirleyen, bunu destekleyecek altyapıyı kuran ve ihtiyaç duymadan önce planlarını test edenlerdir.
Piyasa toparlanmanızı beklemez. Rakipleriniz, sistemleriniz kapalıyken durmaz. Ve müşterileriniz, önemli olduğunda fonlarına erişemediklerinde ya da işlemlerini gerçekleştiremediklerinde size ikinci bir şans vermez. Afet kurtarma planınızı oluşturma zamanı şimdi — her şey hâlâ sorunsuz çalışırken.
Brokerage Afet Kurtarma Stratejisi için Danışmanlık Talep Edin
Brokerliğiniz için gerçekçi RTO ve RPO hedeflerini belirleme konusunda ve bunları operasyonel ile düzenleyici yükümlülüklerinizle uyumlandırma konusunda uzman rehberliği alın. Kriz sistemlerinizi test etmeden önce; altyapı yedekliliğini, ödeme dayanıklılığını, iletişim iş akışlarını ve failover (yedek sisteme geçiş) hazırlığını değerlendirmenize yardımcı olacağız.
Birlikte mevcut süreklilik durumunuzu inceleyecek ve 24/5 trading ortamları için tasarlanmış, yapılandırılmış bir afet kurtarma çerçevesi oluşturacağız.
