🏗️ Software Architecture · Auditor Response · v1.0
Moneyout Software Architecture
Comprehensive overview of the Moneyout platform architecture — including application layers, data flows, external integrations, security model, and infrastructure design. Prepared in response to auditor inquiry under Law No. 6493.
This document describes the software and infrastructure architecture of the Moneyout platform at a level suitable for audit and regulatory review. It does not disclose source code, internal algorithms, cryptographic keys, or specific security configurations.
5
Architecture Layers
3
In-House Apps
6
External Integrations
2
Data Centers
AES-256
Data Encryption
TLS 1.3
Transit Encryption
Confidential — For Audit Use Only · Moneyout Electronic Money and Payment Services Inc.
Executive Summary
Purpose, scope, and architecture overview
Purpose
This document provides a structured description of the software architecture of Moneyout Electronic Money and Payment Services Inc. in response to the audit inquiry regarding information on software architecture. It covers the platform's architectural layers, application designs, data flows, external system integrations, security architecture, and infrastructure model.
For auditors: This document answers (1) how the Moneyout platform is structured architecturally, (2) how components communicate with each other and with external systems, (3) how data flows during payment operations, (4) how security is enforced at each layer, and (5) how the system is deployed and protected against failure.
Platform Summary
The Moneyout platform is a multi-tier, cloud-hosted payment and electronic money platform consisting of three in-house applications communicating over a central REST API, backed by a layered database architecture, secured at network and application level, and integrated with regulated third-party financial service providers.
| Layer | Components | Technology |
|---|---|---|
| Client Layer | Mobile Wallet (iOS/Android), Admin Dashboard (Web), POS Terminal | React Native, Angular 18, Android |
| API Gateway Layer | Core Payment Engine — single REST API entry point for all clients | Laravel 10 (PHP), Laravel Sanctum |
| Business Logic Layer | Wallet, Transfer, KYC, Compliance, Accounting, Notification engines | PHP Service classes, Queue Workers |
| Data Layer | Primary transactional DB, analytics DB, in-memory cache/queue | MS SQL Server 2022, MySQL, Redis |
| Infrastructure Layer | Cloud VMs, Firewall, VPN, SIEM, IAM, Backup | Turkcell Cloud, Fortinet, Active Directory |
Document Control
| Field | Value |
|---|---|
| Document Title | Moneyout — Software Architecture Overview · Auditor Response |
| Version | 1.0 |
| Classification | Confidential — For Audit Use Only |
| Legal Framework | Law No. 6493 on Payment and Security Settlement Systems, Payment Services, and Electronic Money Institutions |
| Owner | Risk and Compliance Unit |
1.1 — High-Level Architecture Overview
Platform-wide system diagram — all components and their relationships
The Moneyout platform follows a layered, API-centric architecture. All client applications communicate exclusively through the Core Payment Engine REST API. No client application accesses the database directly. External systems are integrated via secured API calls from the backend only.
Figure 1 — Moneyout High-Level Architecture
flowchart TB
subgraph CL["CLIENT LAYER"]
direction LR
MW["Mobile Wallet
React Native"]
AD["Admin Dashboard
Angular 18"]
POS["POS Terminal
Android / Magicpay"]
end
subgraph AL["API LAYER"]
FW2["Fortinet Firewall + WAF"]
API["Core Payment Engine
Laravel 10 REST API + WebSocket"]
end
subgraph BL["BUSINESS LOGIC LAYER"]
direction LR
WE["Wallet Engine"]
TE["Transfer Engine"]
KYC["KYC Engine"]
CE["Compliance Engine"]
AE["Accounting Engine"]
NE["Notification Engine"]
end
subgraph EXT["EXTERNAL INTEGRATIONS"]
direction LR
AML["Fineksus AML
PayGate Inspector"]
BANK["FAST / EFT
Interbank Network"]
PAY["Paycell
Bill Payment"]
T3["Tiger 3
Accounting"]
end
subgraph DL["DATA LAYER"]
direction LR
MSSQL["MS SQL Server 2022
Primary DB"]
MYSQL["MySQL
Analytics DB"]
REDIS["Redis
Cache / Queue"]
end
subgraph IL["INFRASTRUCTURE LAYER"]
direction LR
CLOUD["Turkcell Cloud
Tekirdağ + Ankara"]
VPN["SSL VPN
FortiClient"]
SIEM["SIEM
Crypttech"]
IAM["Active Directory
IAM"]
end
MW -->|HTTPS TLS 1.3| FW2
AD -->|HTTPS TLS 1.3| FW2
POS -->|HTTPS TLS 1.3| FW2
FW2 --> API
API --> WE & TE & KYC & CE & AE & NE
CE -->|REST API| AML
TE -->|Secured channel| BANK
WE -->|REST API| PAY
AE -->|Internal sync| T3
WE & TE & KYC & CE & AE --> MSSQL
BL --> MYSQL
API --> REDIS
AL & BL & DL --> CLOUD
Key architectural principle: The Core Payment Engine is the single gateway for all operations. No client app has direct database access. All external system calls originate from the backend API layer only — never from client applications.
1.2 — Architecture Layers Detail
Component responsibilities at each layer
Layer 1 — Client
Mobile Wallet (React Native · iOS & Android) · Admin Dashboard (Angular 18 · Web) · POS Terminal (Android · Magicpay). Presentation layer only — no business logic.
Presentation
Layer 2 — API Gateway
Core Payment Engine (Laravel 10) — single REST API & WebSocket entry point. Middleware stack: Auth (Sanctum), IP-Check, Rate Limiting, Working Hours Guard.
Gateway
Layer 3 — Services
Wallet Engine · Transfer Engine (FAST/EFT/International) · KYC Engine · Compliance Engine · Accounting & GL Engine · Notification Engine · Approval Pool · Commission Engine
Business Logic
Layer 4 — Data
MS SQL Server 2022 (primary transactional) · MySQL (analytics & reporting) · Redis (cache, sessions, job queues)
Persistence
Layer 5 — Infrastructure
Turkcell Cloud (VM hosting) · Fortinet (Firewall + VPN) · Crypttech SIEM (monitoring) · Active Directory (IAM) · Docker (containerization)
Infrastructure
2.1 — Core Payment Engine Architecture
Laravel 10 — internal layered structure and module design
The Core Payment Engine is the central backend. It follows a strict layered architecture — HTTP requests flow through middleware, controllers, service classes, repositories, and ORM models before reaching the database. No layer skips another.
Figure 2 — Core Payment Engine Internal Architecture
flowchart TD
REQ["Incoming HTTP Request (Mobile / Dashboard / POS)"]
subgraph MW["Middleware Stack"]
M1["Sanctum Token Auth"]
M2["IP Allowlist (Checkip)"]
M3["Working Hours Guard (Checkworktime)"]
M4["Rate Limiting"]
end
subgraph CTRL["Controller Layer — Request Handling and Validation"]
C1["Wallet Controller"]
C2["Transfer Controller"]
C3["KYC Controller"]
C4["Compliance Controller"]
C5["Accounting Controller"]
end
subgraph SVC["Service Layer — Business Logic"]
S1["Wallet Service"]
S2["Transfer Service"]
S3["AML / Risk Service"]
S4["Commission Service"]
S5["Notification Service"]
S6["Approval Pool Service"]
end
subgraph REPO["Repository Layer — Data Access Abstraction"]
R1["Eloquent Repositories"]
R2["Query Builders"]
end
subgraph DB2["Data Layer"]
DB1["MS SQL Server 2022"]
DB3["MySQL"]
DB4["Redis Cache/Queue"]
end
REQ --> MW --> CTRL --> SVC --> REPO --> DB2
SVC -->|AML API| EXT1["Fineksus PayGate"]
SVC -->|FAST/EFT| EXT2["Interbank Network"]
SVC -->|Bill Payment| EXT3["Paycell API"]
SVC -->|Accounting sync| EXT4["Tiger 3"]
⚙️
Key Technical Characteristics
Laravel 10 · PHP · REST API · WebSocket · Docker · Ubuntu Server
| API Style | RESTful HTTP API — JSON request/response · Stateless · Token-based authentication via Laravel Sanctum |
| Real-time | WebSocket server for real-time dashboard updates and transaction status notifications to Admin Dashboard |
| Queue System | Laravel Queues + Redis as queue driver + Supervisor for worker management — handles async tasks: AML checks, notifications, settlement jobs |
| Scheduled Jobs | CronJobs on Ubuntu Server — daily settlement, report generation, reconciliation, balance checks, compliance reporting |
| Containerization | Docker — application containers for consistent, reproducible deployments across environments |
| Key Modules | Wallet Engine · Transfer Engine (FAST/EFT/International) · Card Management · KYC Engine · Compliance Engine · Accounting & GL · Notification Engine · Approval Pool · Commission Engine · Agent Management |
| Error Handling | Structured exception handling with detailed audit logging for all operations. All failed transactions logged with full context for compliance review. |
2.2 — Admin Dashboard Architecture
Angular 18 SPA — component architecture and state management
The Admin Dashboard is a single-page application (SPA) built with Angular 18. It communicates exclusively with the Core Payment Engine REST API over HTTPS. All business logic resides in the backend — the dashboard is a presentation and operation layer only.
🖥️
Angular 18 SPA Architecture
Angular 18 · NgRx · Angular Material · ngx-translate · TypeScript
| Architecture Pattern | Component-based SPA with NgRx (Redux pattern) for centralized state management — unidirectional data flow. Actions → Reducers → Store → Selectors → Components. |
| Module Structure | Feature modules: Money Transfer Module · Wallet Module · POS Module · Compliance/AML Module · Reporting Module · Settings Module · User Management Module |
| State Management | NgRx Store — all API calls go through NgRx Effects; state is immutable and predictable. Enables full audit trail of UI state changes. |
| UI Components | Angular Material — standardized, accessible UI component library |
| Multi-language | ngx-translate — Turkish (TR), English (EN), Arabic (AR) with full RTL layout switching |
| Authentication | Sanctum token · Auto-logout on expiry · Session tied to IP allowlist and working hours enforced server-side |
| Role-Based UI | Navigation and feature visibility controlled by user role: Admin · Operator · SuperOperator · Teller · Agent · Risk Officer · Accountant · Internal Control |
| API Communication | Angular HttpClient with interceptors for token injection and error handling. All calls to Core Payment Engine over HTTPS/TLS 1.3. |
2.3 — Mobile Wallet Architecture
React Native Expo — cross-platform iOS & Android
The MoneyOut Wallet is a cross-platform mobile application built with React Native Expo, publishing a single codebase to both Apple App Store and Google Play Store. All business logic resides in the backend API.
📱
React Native Expo Architecture
React Native Expo · TypeScript · iOS & Android · FCM
| Architecture Pattern | Component-based UI with a dedicated API service layer handling all communication with the Core Payment Engine REST API over HTTPS/TLS 1.3 |
| Platform Support | iOS (Apple App Store) and Android (Google Play Store) — single codebase with platform-specific native modules where required |
| Authentication | Token-based authentication (Laravel Sanctum) · Biometric unlock (Face ID / Fingerprint) via device secure enclave |
| Identity Verification | NFC-based Turkish ID (TCKN) card reading for customer identity verification — reads chip data directly from physical ID card during onboarding |
| Push Notifications | Firebase Cloud Messaging (FCM) — real-time transaction alerts and account activity notifications |
| Multi-language | Turkish (TR), English (EN), Arabic (AR) with RTL support |
| Secure Storage | Tokens stored in device secure keychain/keystore — not in plain local storage |
| No Direct DB Access | All API calls go to Core Payment Engine. No sensitive business logic or credentials stored on-device. |
3.1 — Money Transfer Transaction Flow
End-to-end processing of a domestic or international transfer
Every money transfer — domestic (FAST/EFT) or international — follows a mandatory sequential processing pipeline that includes authentication, AML screening, approval rules, and accounting synchronization before completion.
Figure 3 — Money Transfer End-to-End Flow
sequenceDiagram
actor C as Customer / Operator
participant APP as Client App
participant API as Core Payment Engine
participant AML as Fineksus AML
participant DB as MS SQL Server
participant BANK as FAST/EFT Network
participant ACC as Tiger 3 Accounting
participant N as Notification Engine
C->>APP: Initiate Transfer Request
APP->>API: POST /transfer (HTTPS / TLS 1.3)
API->>API: Authenticate (Sanctum Token)
API->>API: Validate Input and Business Rules
API->>AML: AML / Sanctions Screening
AML-->>API: Risk Score + Decision
alt Flagged / High Risk
API->>DB: Save as PENDING (Compliance Hold)
API-->>APP: Status: Pending Compliance Review
else Low Risk Approved
API->>DB: Begin DB Transaction
API->>DB: Debit Sender Balance
API->>BANK: Send to FAST/EFT Network
BANK-->>API: Network Confirmation
API->>DB: Credit Recipient / Confirm
API->>DB: Write Accounting Entry
API->>ACC: Sync Voucher to Tiger 3
API->>N: Trigger Push Notification
N-->>APP: Transaction Success Notification
API-->>APP: Transfer Confirmed
end
Key Processing Controls
- AML screening is mandatory — every transfer is checked against sanctions lists and risk rules before any funds move
- Approval Pool — flagged transactions enter an approval queue requiring authorized operator action before processing
- Atomic database transactions — debit and credit operations are wrapped in a single DB transaction; if any step fails, the entire operation rolls back
- Full audit trail — every step is logged with timestamps, user identifiers, and system states
- Accounting synchronization — confirmed transactions are automatically synced to Tiger 3 for official accounting records
Transfer Status Lifecycle (State Machine)
| # | Status | Description | Next Status |
|---|---|---|---|
| 1 | Entered | Transfer record created in system. AML screening in progress. Sender and beneficiary data captured. | Ready for Payment or Compliance Hold |
| 2 | Compliance Hold | Transfer flagged by AML/risk rules. Awaiting manual review and approval by Risk Officer in the Approval Pool. | Ready for Payment or Rejected |
| 3 | Ready for Payment | AML checks passed and (if required) compliance approval granted. Transfer is ready for settlement. Sender balance committed. | Paid |
| 4 | Paid | Funds dispatched to correspondent network (FAST/EFT) or international partner API. Settlement confirmed. Accounting entry created. | Completed |
| 5 | Completed | End-to-end transfer confirmed as complete. Recipient has received funds (confirmed by bank or correspondent partner callback). Final audit record written. | — Final State — |
| 6 | Refunded | Transfer cancelled after payment due to recipient error or request. Reversal entry created. Commission adjusted. Sender notified. | — Final State — |
Domestic FAST/EFT transactions typically reach Completed status within seconds (FAST) or the same banking day (EFT). International transfers may remain in Paid status for 1–5 business days pending correspondent network confirmation. EFT domestic transfers are subject to a maximum of 200,000 TL per single transaction as set by the interbank network.
3.2 — International Money Transfer Flow
Cross-border transfer processing — from initiation to payout
International money transfers are a core product of the Moneyout platform, governed directly by Law No. 6493 and subject to heightened AML and regulatory controls. Every cross-border transfer passes through additional compliance steps compared to domestic transfers.
1
Customer Initiates International Transfer
Customer submits the transfer via the MoneyOut Wallet app or the Admin Dashboard (for agent/teller-initiated transfers). Required fields: sender identity (TCKN-verified), recipient name, destination country, payout method (bank account / cash pickup / wallet), and transfer amount.
2
Identity & KYC Verification
The KYC Engine confirms the sender's identity verification status (TCKN + biometric verification must be complete). Customer risk profile is checked. First-time international transfer triggers enhanced due diligence (EDD) checks per MASAK and TCMB requirements.
3
Enhanced AML & Sanctions Screening
The transaction is sent to Fineksus PayGate Inspector for full international AML screening: OFAC, UN, EU, and domestic (MASAK) sanctions list matching — 80%+ match threshold triggers Compliance Unit hold. Cross-border risk rules are applied (destination country risk rating, transfer amount thresholds, cumulative limits).
4
Compliance Approval Pool (if required)
High-risk or flagged international transfers enter the Approval Pool in the Admin Dashboard. A Risk Officer or Compliance Officer must manually review and approve/reject before the transfer proceeds. All decisions are logged with justification for the audit trail.
5
Transfer Routing to Correspondent Partner
Approved transfers are routed to the relevant international correspondent partner network based on the destination country and payout method. The Core Payment Engine communicates with the partner's API over a secured, encrypted channel (HTTPS/TLS 1.3).
6
Atomic Debit & Settlement Record
Upon partner confirmation of acceptance, the sender's wallet is debited atomically in MS SQL Server. The transaction is recorded with full metadata: exchange rate at time of transfer, fee breakdown, correspondent reference number, and expected delivery time.
7
Accounting Entry & Regulatory Reporting
The Accounting Engine writes the cross-border transaction entry to Tiger 3 for official records. Cross-border transaction data is available for TCMB reporting obligations (monthly/annual cross-border transfer reports).
8
Customer Notification & Tracking
Push notification sent to customer (FCM) with transfer confirmation, reference number, and expected delivery window. Customer can track transfer status in the wallet app until payout is confirmed by the correspondent network.
Regulatory note: All international money transfers are subject to TCMB cross-border reporting requirements and MASAK obligations under Law No. 6493 and Anti-Money Laundering Law No. 5549. All international transfer records are retained for a minimum of 5 years as required by regulation.
3.3 — Wallet Operations Flow
Deposit, withdrawal, and wallet-to-wallet transfer processing
1
Customer Initiates Wallet Operation
Customer submits a deposit, withdrawal, or wallet-to-wallet transfer request via the MoneyOut Wallet app. Request is sent over HTTPS/TLS 1.3 to the Core Payment Engine.
2
Authentication & Authorization
Sanctum token is validated. The API verifies the requesting user owns the wallet account. Rate limits and daily limits are checked against the customer profile.
3
KYC & Compliance Check
The KYC Engine verifies customer identity verification status. The Compliance Engine passes the operation to Fineksus AML for risk scoring. Operations by flagged customers are held for compliance review.
4
Balance & Limit Validation
The Wallet Engine checks available balance, daily transaction limits, single-transaction limits, and any active restrictions on the account per the regulatory limits defined in the system.
5
Atomic Database Write
All balance changes are performed within a single atomic database transaction on MS SQL Server 2022. The operation either fully succeeds or fully rolls back — no partial states are possible.
6
Accounting Entry & Notification
The Accounting Engine writes the corresponding general ledger entry. The Notification Engine dispatches a real-time push notification (FCM) to the customer confirming the operation.
3.4 — POS Payment Flow
Card and digital payment processing at merchant / agent locations
POS payments are processed through Magicpay POS terminals (Android-based) deployed at merchant and agent representative locations. The terminal communicates exclusively with the Core Payment Engine — no direct card network access from the terminal itself.
1
Customer Presents Card / QR at Terminal
Customer presents a card (or QR code) at the Magicpay POS terminal. The terminal reads the card data and initiates an authorization request to the Core Payment Engine over HTTPS/TLS 1.3.
2
Terminal Authentication
The POS terminal authenticates to the Core Payment Engine using its registered device credentials (API key + device ID). The system validates the terminal is active, assigned to a registered merchant, and within its operating limits.
3
AML & Risk Screening
The transaction is passed to the Compliance Engine for AML screening via Fineksus PayGate Inspector. POS transactions above defined thresholds trigger additional scrutiny per the 59 active fraud/security rules.
4
3D-Secure Processing (if applicable)
For card transactions requiring 3D-Secure authentication, the flow includes an additional identity confirmation step. The transaction holds pending customer authentication confirmation before the payment is authorized.
5
Authorization & Atomic DB Write
Upon approval, the Core Payment Engine writes the transaction atomically to MS SQL Server: merchant account credited, customer account (or card) debited, commission calculated and recorded, transaction reference generated.
6
Settlement & Accounting Sync
Approved POS transactions are included in the daily settlement batch. The Accounting Engine creates the corresponding GL entry and syncs to Tiger 3. Merchant settlement is processed per the agreed settlement cycle.
7
Receipt & Confirmation
Authorization response is returned to the POS terminal within seconds. Terminal prints/displays receipt. The transaction is visible in the Admin Dashboard POS module for monitoring and reconciliation.
3.5 — Customer Onboarding & KYC Flow
Identity verification and customer registration process
All customers must complete a Know Your Customer (KYC) process before transacting. Moneyout performs identity verification in compliance with TCMB and MASAK requirements, using biometric identity verification integrated with the Turkish ID infrastructure.
1
Registration Initiation
Customer downloads the MoneyOut Wallet app and starts registration. Basic information collected: name, TC Identity Number (TCKN), phone number, email.
2
NFC Identity Verification
Customer holds their physical Turkish ID card (Nüfus Cüzdanı) against the phone's NFC reader. The app reads the chip data directly from the ID card and extracts the identity information securely. This ensures the physical document is present and authentic.
3
Biometric Face Verification
The customer takes a live selfie which is compared against the photo on the NFC-read ID card using biometric matching. Liveness detection prevents spoofing (photo or video attacks). Match score is recorded and stored.
4
TCKN Validation
The TC Identity Number is validated against government infrastructure. This confirms the identity number is valid and belongs to a living person matching the provided personal data.
5
AML Customer Risk Screening
The new customer's identity data is passed to Fineksus PayGate Inspector for screening against sanctions lists (OFAC, UN, EU, MASAK). A customer risk score is assigned. High-risk customers are flagged and require Compliance Unit review before account activation.
6
Account Creation & Activation
Upon successful KYC, the customer account and electronic wallet are created in MS SQL Server. Transaction limits are set according to the customer's KYC tier. The customer receives confirmation and can begin transacting within regulatory limits.
7
Ongoing KYC & Re-verification
Customer data is subject to periodic re-verification. Any change in customer risk profile (e.g., appearing on a sanctions list after onboarding) triggers automatic account review via the SIEM + AML monitoring systems. Compliance Unit is alerted immediately.
3.6 — AML & Compliance Workflow
How flagged transactions are handled and MASAK reporting is generated
The AML compliance workflow defines how the system responds to high-risk transactions, manages the approval pool, generates regulatory reports, and maintains the audit trail required by MASAK (Mali Suçları Araştırma Kurulu) and TCMB.
Figure 6 — AML Compliance Workflow
flowchart TD
TX["Transaction Initiated"] --> AML["Fineksus AML Screening
PayGate Inspector API"]
AML --> SCORE{"Risk Score
Evaluation"}
SCORE -->|"Low Risk
Score < threshold"| APPROVE["Auto-Approved
Process Normally"]
SCORE -->|"Medium Risk
80%+ sanctions match"| HOLD["Compliance Hold
Approval Pool"]
SCORE -->|"High Risk
Blocked"| BLOCK["Transaction Blocked
Customer Notified"]
HOLD --> REVIEW["Risk Officer /
Compliance Officer
Manual Review"]
REVIEW -->|"Approved"| APPROVE
REVIEW -->|"Rejected"| REJECT["Transaction Rejected
Record Retained"]
REVIEW -->|"STR Required"| STR["Suspicious Transaction
Report (STR)
Filed with MASAK"]
APPROVE --> LOG["Full Audit Log
Recorded in DB"]
BLOCK --> LOG
REJECT --> LOG
STR --> LOG
| Action | Trigger | Handled By | Outcome |
|---|---|---|---|
| Auto-Approve | Low risk score, no sanctions match | System (automatic) | Transaction processes immediately |
| Compliance Hold | 80%+ sanctions list match OR rule trigger | Risk Officer (Admin Dashboard) | Transaction held pending manual review |
| Auto-Block | 100% sanctions match OR blocked customer | System (automatic) | Transaction rejected; customer notified; event logged |
| STR Filing | Compliance officer determines suspicious activity | Compliance Unit | Suspicious Transaction Report filed with MASAK |
| SAR / CTR | Regulatory thresholds exceeded | Compliance Unit | Regulatory report generated and submitted to MASAK/TCMB |
59 Active Rules: The Fineksus PayGate Inspector integration enforces 59 active fraud and security rules configured by the Compliance Unit. These rules cover sanctions matching, behavioral anomalies, velocity checks, amount thresholds, geographic risk, and customer risk profiling. Rules are managed and reviewed through the Admin Dashboard Compliance Module.
4.1 — External Integration Architecture
All third-party system connections — method, protocol, and direction
Integration principle: All external system integrations are initiated exclusively from the Core Payment Engine backend. No client application communicates directly with any external system. All traffic traverses the Fortinet Firewall and is encrypted using TLS 1.3.
Fineksus AML
Fineksus Bilişim ve Çözümleri Ticaret A.Ş.
PayGate Inspector API — real-time AML screening, sanctions checking, and customer risk scoring. Called synchronously for every financial transaction before processing.
FAST / EFT Network
Interbank Payment Network
Domestic money transfer network for FAST (instant) and EFT (batch) transactions. Used for sending and receiving funds between Moneyout and Turkish bank accounts.
Paycell
Paycell Ödeme Hizmetleri A.Ş.
Bill payment and utility payment integration. Enables customers to pay bills directly from their Moneyout Wallet through the Paycell billing infrastructure.
Tiger 3 (Logo)
Logo Software / Antsoft
Accounting system integration. Confirmed transactions generate accounting vouchers automatically synced to Tiger 3 for official double-entry bookkeeping and financial reporting.
Magicpay POS
Magicpay Teknoloji A.Ş.
POS terminal software integration. Android-based POS terminals communicate with the Core Payment Engine for transaction authorization, settlement, and merchant management.
Firebase FCM
Google Firebase
Push notification delivery for mobile wallet customers. The Notification Engine sends transaction confirmations, alerts, and account activity notifications via FCM to customer devices.
RIA Money Transfer
Euronet Worldwide / RIA Financial Services
International money transfer correspondent network. The Core Payment Engine routes eligible cross-border transfers through the RIA API for payout in 160+ countries via cash pickup and bank deposit. Regulated partner under Law No. 6493.
Korona Pay
Korona Pay International
International money transfer correspondent for CIS countries and Eastern Europe. Transfers are routed to Korona Pay when the destination country and payout method match Korona's coverage network. Provides cash pickup and home delivery payout options.
Aysar
Aysar International Money Transfer
International money transfer correspondent specializing in Middle East and Gulf Cooperation Council (GCC) corridors. Handles transfers routed to Gulf countries with bank deposit and cash pickup payout options.
Tranglo
Tranglo Sdn Bhd
International money transfer correspondent for Southeast Asia and Asia-Pacific corridors. Covers Malaysia, Indonesia, Philippines, Bangladesh and other high-volume remittance corridors. Provides bank credit and mobile wallet payout.
Albaraka Bank
Albaraka Türk Katılım Bankası A.Ş.
Banking API integration for EFT / FAST transactions and account services. Used for settlement and fund flow operations between Moneyout and the banking system. Integration via Paygate banking middleware API.
Vakif Bank
Türkiye Vakıflar Bankası T.A.O.
Banking API integration for EFT / FAST domestic fund transfers and settlement. Provides IBAN validation and account inquiry services. Integration via Paygate banking middleware API.
Finans Bank (QNB)
QNB Finansbank A.Ş.
Banking API integration for EFT / FAST domestic transactions and settlement reconciliation. Supports multi-bank settlement architecture. Integration via Paygate banking middleware API.
Integration Summary Table
| # | System | Vendor | Method | Direction | Protocol | Trigger |
|---|---|---|---|---|---|---|
| 1 | Fineksus AML | Fineksus | REST API | Outbound | HTTPS / TLS 1.3 | Every financial transaction |
| 2 | FAST / EFT Network | Interbank | Secured API | Bidirectional | HTTPS / TLS 1.3 | Domestic transfer initiation / receipt |
| 3 | Paycell | Paycell A.Ş. | REST API | Outbound | HTTPS / TLS 1.3 | Bill payment request from wallet |
| 4 | Tiger 3 Accounting | Logo / Antsoft | Internal Sync | Outbound | Local network | Transaction confirmation |
| 5 | Magicpay POS | Magicpay | REST API | Bidirectional | HTTPS / TLS 1.3 | POS payment authorization |
| 6 | Firebase FCM | FCM API | Outbound | HTTPS / TLS 1.3 | Transaction events & alerts | |
| 7 | RIA Money Transfer | Euronet / RIA | REST API | Outbound | HTTPS / TLS 1.3 | International transfer routing |
| 8 | Korona Pay | Korona Pay Intl. | REST API | Outbound | HTTPS / TLS 1.3 | International transfer routing (CIS) |
| 9 | Aysar | Aysar Intl. | REST API | Outbound | HTTPS / TLS 1.3 | International transfer routing (Gulf) |
| 10 | Tranglo | Tranglo Sdn Bhd | REST API | Outbound | HTTPS / TLS 1.3 | International transfer routing (SEA) |
| 11 | Albaraka Bank | Albaraka Türk | Paygate API | Bidirectional | HTTPS / TLS 1.3 | EFT/FAST settlement |
| 12 | Vakif Bank | T. Vakıflar Bankası | Paygate API | Bidirectional | HTTPS / TLS 1.3 | EFT/FAST settlement |
| 13 | Finans Bank (QNB) | QNB Finansbank | Paygate API | Bidirectional | HTTPS / TLS 1.3 | EFT/FAST settlement |
4.2 — GIB Regulatory Reporting Architecture
Mandatory Turkish Tax Authority (Gelir İdaresi Başkanlığı) compliance reports generated by the platform
Legal basis: MoneyOut is required under Turkish financial regulation to submit periodic transaction reports to the GIB (Gelir İdaresi Başkanlığı — Turkish Revenue Administration) covering international money transfers and digital wallet activity. These reports are generated automatically by the Core Payment Engine from operational transaction data.
The platform generates five distinct GIB report types, each covering a different category of regulated financial activity. All reports are produced in GIB-specified XML/CSV format, validated against schema rules, and submitted via the GIB e-Beyanname portal or secure API channel.
GIB Report Inventory
| Report Code | Full Name | Transaction Type Code | Coverage | Frequency |
|---|---|---|---|---|
| UPTGI | Uluslararası Para Transferi Gönderilen | UP001 |
International money transfers — outgoing (sent from Turkey) | Monthly |
| UPTGE | Uluslararası Para Transferi Gelen | UP005 |
International money transfers — incoming (received into Turkey) | Monthly |
| YT | Yurt İçi Transfer | 00001 |
Domestic wallet-to-wallet money transfers | Monthly |
| EPKBB | Elektronik Para Kullanıcı Bakiye Bilgisi | EP002 |
Wallet customer balance snapshots at reporting period end | Monthly |
| EPHPYCNI | Elektronik Para Hesabına Para Yükleme / Çekme | Deposit: OH011 / Withdrawal: OH010 |
Wallet deposit and withdrawal transactions | Monthly |
Report Generation Architecture
1
Transaction Data Collection
All financial transactions (transfers, deposits, withdrawals, wallet operations) are recorded in MS SQL Server with full regulatory metadata: sender/receiver identity (TCKN, passport number, nationality), amounts, currencies, exchange rates, correspondent partner reference, and timestamps. This data forms the raw source for all GIB reports.
2
Report Data Extraction
At the end of each reporting period, the Reporting & Analytics Module queries the transaction database to extract all reportable events. Filters are applied by transaction type, date range, and status (only completed/settled transactions are included). Turkish character normalization is applied to all name fields (ş→s, ı→i, ç→c, ğ→g, ü→u, ö→o) as required by GIB format specifications.
3
Exchange Rate Calculation
For international transfers, the TRY-equivalent amount is calculated using the TCMB official exchange rate on the transaction date. The exchange rate is stored at the time of each transaction to ensure accurate historical reporting. This rate is embedded in UPTGI and UPTGE reports as required by GIB schema.
4
Report File Generation & Validation
The Reporting Module generates structured report files (XML/CSV) conforming to GIB schema specifications for each report type. Files are validated against mandatory field requirements and business rules before submission. Errors or schema violations trigger internal alerts for correction before the submission deadline.
5
GIB Portal Submission & Confirmation
Validated report files are submitted to the GIB e-Beyanname portal by the designated compliance officer. Submission acknowledgment numbers are recorded in the audit log. Submitted report files and acknowledgments are retained for a minimum of 5 years in accordance with Turkish financial record-keeping requirements.
Data Fields by Report Type
| Report | Key Data Fields | Identity Required |
|---|---|---|
| UPTGI (Outgoing Intl.) |
Transaction date, amount (original currency + TRY equivalent), TCMB exchange rate, sender identity (TCKN/passport, nationality, address), beneficiary name & country, correspondent partner name, payout method | Sender: TCKN or Passport Beneficiary: name + country |
| UPTGE (Incoming Intl.) |
Transaction date, amount (original currency + TRY equivalent), source country, receiver identity (TCKN/passport, nationality), correspondent partner reference | Receiver: TCKN or Passport |
| YT (Domestic W2W) |
Transaction date, amount (TRY), sender wallet ID + identity, receiver wallet ID + identity, transaction reference number | Both sender & receiver: TCKN |
| EPKBB (Wallet Balances) |
Reporting period end date, wallet customer identity (TCKN/passport), wallet account balance (TRY), account status (active/blocked) | Account holder: TCKN or Passport |
| EPHPYCNI (Deposits/Withdrawals) |
Transaction date, operation type (deposit OH011 / withdrawal OH010), amount (TRY), wallet customer identity, source/destination (bank IBAN or card masked), transaction reference | Wallet customer: TCKN or Passport |
Compliance note: Failure to submit GIB reports on time or with incorrect data may result in administrative sanctions under Turkish tax law. MoneyOut's Compliance Unit is responsible for the accuracy, completeness, and timely submission of all GIB reports. All submitted reports and their source data are retained in immutable audit logs for 5 years.
5.1 — Security Architecture Overview
Defense-in-depth — six security layers from perimeter to data
Moneyout applies a defense-in-depth security model with six distinct layers. A threat must bypass all layers to reach sensitive data. Each layer operates independently so the failure of one does not compromise the others.
Layer 1 — Perimeter Security
Fortinet Next-Generation Firewall (NGFW) · Deep Packet Inspection (DPI) · IDS/IPS (Intrusion Detection & Prevention) · VLAN network segmentation · DMZ for externally-facing services · All inbound traffic filtered before reaching application servers · Managed by Arrtech Teknoloji
Layer 2 — Network & Remote Access Security
SSL VPN (Fortinet FortiClient) · Mandatory MFA for all remote access (OTP + biometric + certificate) · No direct server access without VPN · Secure tunnel for all administrative operations · IP-based access controls on all system interfaces
Layer 3 — Application Security
Laravel Sanctum token authentication · Checkip middleware (IP allowlist) · Checkworktime middleware (working hours restriction) · Role-based access control (RBAC) at API level · Input validation on all endpoints · Rate limiting · CSRF protection · Parameterized queries (SQL injection prevention)
Layer 4 — Data Security
AES-256 encryption for all data at rest · TLS 1.3 for all data in transit · HSM (Hardware Security Module) for cryptographic key management · Sensitive fields (TCKN, card data) stored encrypted · Database access restricted to application service accounts only — no direct external DB connections
Layer 5 — Identity & Access Management
Microsoft Active Directory for centralized IAM · Group Policy enforcement · Principle of least privilege · Automated user provisioning/deprovisioning · All internal system access governed by AD roles · Supported by Ldap Bilgi Teknolojileri for technical maintenance
Layer 6 — Monitoring, Detection & Response
SIEM (Crypttech / Arrtech) — centralized aggregation of all system, network, and security logs · Real-time correlation rules and automated alerting · Log integrity maintained with timestamps · DLP (Data Loss Prevention) · EDR (Endpoint Detection & Response) · 24/7 security event monitoring
5.2 — Authentication & Access Control Model
How users and systems are authenticated and authorized
| User / System Type | Authentication Method | Authorization | Additional Controls |
|---|---|---|---|
| Mobile Wallet customers | Username + Password → Sanctum Token + Biometric unlock (Face ID / Fingerprint) | Account-level: can only access own wallet data | NFC ID verification for onboarding; FCM device registration |
| Admin Dashboard users | Username + Password → Sanctum Token | Role-based (Admin / Operator / Teller / Risk Officer / Accountant etc.) | IP Allowlist (Checkip) · Working hours restriction (Checkworktime) |
| POS Terminal | Device-level API credentials → Sanctum Token | Merchant-scoped — can only process transactions for registered terminal | IP restriction · Device registration |
| Internal staff (VPN/AD) | Active Directory credentials + MFA (OTP + certificate) | AD Group Policy — role-based server and system access | Must connect via SSL VPN — no direct access without VPN |
| External APIs | API key / Shared secret | System-level — specific API endpoints only | IP allowlisting · TLS mutual authentication where applicable |
Admin Role Matrix
| Role | Access Scope |
|---|---|
| Admin | Full system access — all modules, all configuration |
| SuperOperator | Full operations access — transfers, wallets, POS — no system configuration |
| Operator | Operational access — transaction processing and monitoring |
| Teller | Counter-level operations — customer service, transaction initiation |
| Agent | Agent branch operations — limited to assigned agent scope |
| Risk Officer | Compliance dashboard — AML alerts, approval pool, risk monitoring |
| Accountant | Financial reports, accounting entries, reconciliation |
| Internal Control | Read-only audit access — all modules, no transaction initiation |
Security Policy Parameters
| Control | Parameter | Applies To |
|---|---|---|
| API Token Lifetime | 3 hours (configurable) | All authenticated sessions (Admin Dashboard, Mobile Wallet, POS) |
| Token Revocation | Immediate on logout | Sanctum token invalidated server-side on logout |
| Password Lockout | After 5 consecutive failed attempts | Admin Dashboard users — account locked; requires admin unlock or password reset |
| PIN Lockout | After 3 consecutive failed attempts | Wallet customers — PIN locked; requires OTP-based reset via SMS/email |
| Password Policy | Minimum 6 characters · Letters + Numbers + Special characters required | All platform users (Admin, Operator, Teller, Agent) |
| OTP Validity | Time-limited (single use) | Sensitive operations: PIN reset, password reset, high-value transaction confirmation |
| Session Binding | Token bound to device & IP at issuance | Enforced by Checkip middleware — token cannot be used from a different IP without re-authentication |
| Working Hours Enforcement | Checkworktime middleware active on all Admin/Teller/Agent APIs | API requests outside configured business hours are rejected with HTTP 403 |
5.3 — Encryption Model
Data-at-rest and data-in-transit encryption standards
| Scope | Standard | Applied To |
|---|---|---|
| Data at Rest | AES-256 | All database contents on MS SQL Server 2022; backup files; sensitive fields (identity documents, card data) |
| Data in Transit | TLS 1.3 | All client-to-API communication; all API-to-external-service communication; VPN tunnel encryption |
| Key Management | HSM | Hardware Security Module for cryptographic key storage — keys never exist in plaintext software memory |
| Password Storage | bcrypt | All user passwords hashed with bcrypt — never stored in plaintext or reversible form |
| API Tokens | SHA-256 Hash | Laravel Sanctum tokens stored as SHA-256 hashes — raw token shown to user only once at issuance |
| Backup Encryption | AES-256 | All cloud backups (Turkcell Dijital) are encrypted before transmission and storage |
6.1 — Deployment & Infrastructure Architecture
Cloud hosting, containerization, DR strategy, and backup model
🟢 Production — Tekirdağ Data Center
Turkcell Cloud / Superonline İletişim Hiz.A.Ş. · Active
- All in-house applications hosted here (Core API, Admin Dashboard, Wallet backend, Help Center, Orchestra, VDR)
- Ubuntu Server (Linux) virtual machines on Turkcell Cloud infrastructure
- Docker containerization for consistent, reproducible deployments
- MS SQL Server 2022 + MySQL + Redis on dedicated VMs
- Fortinet Firewall protecting all inbound/outbound traffic
- SIEM monitoring all security events in real time
- Daily backups shipped to Turkcell Cloud Backup (Ankara)
🔵 Disaster Recovery — Ankara Data Center
Turkcell Cloud · Standby — Activated on failure / disaster
- Mirror of all production systems and databases
- Activated in case of production failure, cyber attack, or physical disaster
- Database replicated from Tekirdağ — point-in-time recovery capability
- Tested periodically to confirm recovery time objectives (RTO) are met
- Separate physical location ensures geographic redundancy
- All backups from Turkcell Cloud Backup Service stored here
Figure 4 — Deployment Architecture
flowchart LR
subgraph PROD["PRODUCTION — Tekirdag Data Center"]
FW["Fortinet Firewall"]
subgraph APPS["Application VMs (Ubuntu Server)"]
API2["Core Payment Engine
Laravel 10 + Docker"]
ADMIN["Admin Dashboard
Angular 18"]
OPS["Help Center + Orchestra + VDR"]
end
subgraph DBS["Database VMs"]
SQL["MS SQL Server 2022"]
MY["MySQL"]
RD["Redis"]
end
SIEM2["SIEM
Crypttech"]
end
subgraph DR["DISASTER RECOVERY — Ankara Data Center"]
FWDR["Fortinet Firewall DR"]
APPSDR["Application VMs
Standby"]
SQLDR["MS SQL Server
Replica"]
end
subgraph BACKUP["CLOUD BACKUP"]
CB["Turkcell Dijital
Cloud Backup"]
end
INTERNET["Internet / Clients"] --> FW
FW --> APPS
APPS --> DBS
DBS -->|"Daily Backup"| CB
SQL -->|"Replication"| SQLDR
APPS -.->|"Failover"| APPSDR
🐳
Deployment & Operations Model
Docker · Ubuntu Server · Supervisor · CronJobs
| Containerization | Docker — all application components run as containers. Ensures environment consistency. Simplifies deployment and rollback. |
| Process Management | Supervisor — manages and auto-restarts Laravel queue workers and background processes after any failure without manual intervention. |
| Scheduled Tasks | CronJobs on Ubuntu Server — daily settlement, reconciliation, report generation, balance checks, and compliance reporting. |
| Operating System | Ubuntu Server (Linux) for all in-house apps. Windows Server for Active Directory and Tiger 3 accounting only. |
| Backup | Daily backups via Turkcell Dijital İş Servisleri A.Ş. — encrypted, stored independently, available for point-in-time restoration. |
6.2 — Database Architecture
Data store design, responsibilities, and data partitioning
Figure 5 — Database Architecture and Data Flow
flowchart LR
API3["Core Payment Engine
(Laravel 10)"]
subgraph DBS2["Data Stores"]
MSSQL2["MS SQL Server 2022
Primary Transactional DB
Customers, Wallets
Transactions, Compliance
Accounting, Agents
KYC, Notifications"]
MYSQL2["MySQL
Analytics and Reporting DB
Report data
Aggregated stats"]
REDIS2["Redis
Cache and Queue Store
Sessions, Job queues
Real-time data
Rate limit counters"]
end
API3 -->|"Write/Read core data"| MSSQL2
API3 -->|"Write analytics events"| MYSQL2
API3 -->|"Cache and Queue jobs"| REDIS2
MSSQL2 -->|"Replicated to"| DR2["Ankara DR
MS SQL Replica"]
MYSQL2 & MSSQL2 -->|"Daily backup"| BK["Turkcell Cloud
Backup"]
| Data Store | Type | Role | What Is Stored | DR / Backup |
|---|---|---|---|---|
| MS SQL Server 2022 | Relational RDBMS | Primary | All core transactional data: customer profiles, wallet accounts, transaction records, KYC data, compliance events, accounting entries, agent data, commission records, system configuration | Replicated to Ankara DR · Daily backup via Turkcell Cloud Backup |
| MySQL | Relational RDBMS | Secondary | Analytics and reporting data — aggregated transaction statistics, performance metrics, BI-ready datasets. Offloads analytical queries from primary DB. | Backed up via Turkcell Cloud Backup |
| Redis | In-memory / Key-Value | Supporting | Session caching, Laravel job queues, rate limit counters, real-time state for WebSocket, temporary OTP codes | Ephemeral — recoverable from primary DB on restart |
Data access principle: No application, external system, or user accesses databases directly. All database access is mediated exclusively through the Core Payment Engine service layer using dedicated service accounts with minimum required permissions.
7.1 — Audit Logging & Data Retention Architecture
Log management, data retention periods, and regulatory compliance
Regulatory basis: Data retention requirements are governed by Law No. 6493 (payment records), Anti-Money Laundering Law No. 5549 (5-year minimum retention for AML-related records), and TCMB payment services regulations. All retention periods comply with or exceed the regulatory minimums.
Audit Log Architecture
Every transaction, user action, system event, and security event generates an immutable audit log entry. Logs are written to MS SQL Server with a timestamp, user/system identifier, action type, before/after state, and source IP. Log entries cannot be deleted or modified by application users.
| Log Type | What Is Logged | Storage | Retention |
|---|---|---|---|
| Transaction Logs | All financial transactions: transfers, wallet operations, POS payments. Full detail: amount, currency, parties, status, timestamps, reference numbers, AML score. | MS SQL Server 2022 (primary) + Turkcell Cloud Backup | Minimum 10 years (exceeds 5-year MASAK/TCMB requirement) |
| AML / Compliance Logs | All AML screening results, risk scores, compliance holds, approval/rejection decisions, STR filings | MS SQL Server 2022 + Turkcell Cloud Backup | Minimum 10 years per MASAK Law No. 5549 |
| User Action Logs | All Admin Dashboard and API actions: login/logout, data access, configuration changes, approval pool actions, with user ID and IP | MS SQL Server 2022 | 5 years minimum |
| System & Security Logs | Authentication events, failed logins, IP denials, rate limit breaches, system errors, infrastructure events | SIEM (Crypttech/Arrtech) + MS SQL Server | 2 years minimum (SIEM) + longer in DB |
| KYC & Identity Logs | Customer onboarding records, NFC verification results, biometric match scores, TCKN validation results | MS SQL Server 2022 (encrypted) + Turkcell Cloud Backup | Lifetime of customer relationship + 10 years |
| API Access Logs | All inbound API requests: endpoint, method, response code, latency, source IP, token reference | Application server logs + SIEM | 1 year (operational) + aggregated in DB |
Log Integrity & Tamper Protection
- All audit logs are written with timestamps and sequence numbers — gaps or out-of-order entries are automatically flagged
- SIEM collects logs from all sources independently — even if the application database were compromised, SIEM retains an independent copy
- Database-level audit logs use append-only write patterns — no UPDATE or DELETE operations are permitted on audit tables
- Daily backups of all log data are transmitted to Turkcell Dijital Cloud Backup — geographically separate from production
- Log access is restricted to Compliance Officers, Internal Control, and Admins — all log access is itself logged
7.2 — Technology Stack Reference
Complete inventory of all technologies, frameworks, and versions in use
In-House Application Technologies
| Component | Technology | Purpose |
|---|---|---|
| Core Payment Engine | Laravel 10 (PHP) · REST API · WebSocket · Laravel Sanctum · Laravel Queues | Central backend — all payment business logic |
| Admin Dashboard | Angular 18 · TypeScript · NgRx · Angular Material · ngx-translate | Operations and management web application |
| Mobile Wallet | React Native Expo · TypeScript · Firebase FCM · NFC module | Customer-facing iOS & Android app |
Infrastructure & Data Technologies
| Technology | Type | Role |
|---|---|---|
Microsoft SQL Server 2022 | Relational RDBMS | Primary transactional database for all core operations |
MySQL | Relational RDBMS | Analytics and reporting secondary database |
Redis | In-memory Key-Value Store | Caching, session management, job queues |
Docker | Containerization | Application deployment containers |
Ubuntu Server (Linux) | Operating System | All in-house application server VMs |
Windows Server | Operating System | Active Directory and Tiger 3 accounting |
Supervisor | Process Manager | Laravel queue worker management |
CronJobs | Scheduler | Automated batch processing and reporting tasks |
Security & Infrastructure Technologies
| Technology | Vendor | Role |
|---|---|---|
| Fortinet NGFW & FortiClient VPN | Fortinet / Arrtech Teknoloji | Perimeter firewall, IDS/IPS, SSL VPN with MFA |
| SIEM — Crypttech | Arrtech Teknoloji | Security event monitoring, log aggregation, alerting |
| Microsoft Active Directory | Microsoft / Ldap Bilgi | Centralized IAM, RBAC, Group Policy |
| HSM (Hardware Security Module) | — | Cryptographic key management for AES-256 encryption |
| AES-256 | Standard | Data-at-rest encryption |
| TLS 1.3 | Standard | Data-in-transit encryption for all communications |
| Firebase FCM | Push notification delivery for mobile app |
Third-Party Service Technologies
| System | Vendor | Technology / Integration |
|---|---|---|
| AML / Compliance | Fineksus Bilişim | PayGate Inspector REST API · 59 active rules |
| Accounting ERP | Logo Software / Antsoft | Tiger 3 · SQL Server-based · Windows Server |
| POS Terminal Software | Magicpay Teknoloji | Android-based POS · REST API integration |
| Cloud Hosting | Superonline İletişim | Turkcell Virtual Data Center · Tekirdağ & Ankara |
| Cloud Backup | Turkcell Dijital | Software-based encrypted cloud backup · Daily |
| Bill Payment | Paycell Ödeme | Paycell REST API · Integrated into Wallet Engine |
Notes & Declaration
Compliance declaration and document information
Legal Framework: This document is prepared in response to an audit inquiry and in accordance with the requirements under Law No. 6493 on Payment and Security Settlement Systems, Payment Services, and Electronic Money Institutions. All information reflects the current state of the institution's information systems as of February 2026.
Notes
- This document describes the architecture at a level appropriate for regulatory and audit review. Source code, internal algorithms, cryptographic keys, and specific security configurations are not disclosed.
- The architecture described reflects the current production state as of February 2026. Material architectural changes will be reported to the Compliance Unit and TCMB where required.
- All in-house applications are developed and maintained by Moneyout's internal Information Systems department (5 dedicated staff).
- Third-party integrations (Fineksus, Magicpay, Paycell, etc.) are governed by formal written service agreements. Vendor architecture and security is their responsibility under the respective contracts.
- The platform is subject to periodic internal security reviews and penetration testing as part of the ongoing compliance program.
Document Information
| Field | Value |
|---|---|
| Company | Moneyout Electronic Money and Payment Services Inc. |
| Company Code | 00917 |
| Tax No. | 622 175 8445 |
| Address | Eşentepe Mah. Büyükdere Cad. Metrocity No: 171 İç Kapı No: 15 Şişli/İstanbul, Turkey |
| Classification | Confidential — For Audit Use Only |
Confidential — For Audit Use Only · Moneyout Electronic Money and Payment Services Inc.