Your users' financial data
is personal and powerful

Encryption

All financial data stored by OpenDinar is encrypted using AES-256 — the same standard used by banks and governments worldwide. This applies to account information, transaction history, identity data, and all other user-linked content.

All data in transit between your application, OpenDinar's API, and Serbian bank systems is protected using TLS 1.2 and TLS 1.3. Older, insecure protocol versions (SSL, TLS 1.0, TLS 1.1) are explicitly disabled across all endpoints.

Access Control

Developer access to the OpenDinar API is controlled through API keys. These keys are:

• Hashed for lookup — every request authenticates your key against a one-way SHA-256 hash. Full-key storage is being removed from the database before live bank data is enabled.
• Scoped by environment — keys are issued per environment. Only sandbox keys (od_test_sk_*) exist today; live keys (od_live_sk_*) will be issued once OpenDinar is licensed, and a sandbox key will never reach live bank data.
• Rate limited — account, login and sign-up endpoints enforce rate limits today. Rate limiting across every banking endpoint is in progress and will be in place before live bank data is enabled.
• Revocable instantly — Keys can be revoked from the dashboard immediately. Revoked keys stop working within seconds.

Webhook payloads are HMAC-signed using your webhook secret. This allows your server to cryptographically verify that every incoming event genuinely originated from OpenDinar and has not been tampered with in transit.

Permission Model

OpenDinar is built on a consent-first architecture. No bank account data is ever accessed without an explicit user action.

Here is how every bank connection works:

1. The end user opens your application and chooses to connect their bank account.
2. Your application launches the OpenDinar Link Widget — a secure, OpenDinar-controlled interface.
3. The user selects their bank and authenticates directly with that bank. OpenDinar never sees the user's bank password.
4. The bank issues a secure authorization token to OpenDinar. Your application receives an item_id to reference this connection.
5. Only the data types your application requested are accessible — not all data the bank holds on the user.

Data Handling

What we store

OpenDinar stores the data necessary to fulfil API requests on behalf of developers:

• Account metadata (account name, type, IBAN, currency)
• Transaction history (amount, date, merchant, category)
• Balance snapshots (current and available)
• Identity data (name, address, phone, email) — only when the Identity product is enabled
• Bank connection tokens (never your user's bank credentials). An encrypted token store is being built before the first live bank connection.

What we never store

• Bank login passwords or PINs — these are entered directly into the bank's system via the Link Widget
• Payment card numbers
• Any data beyond what your application explicitly requested

Retention

Transaction and account data is retained for as long as the bank connection is active. When a developer deletes a connection or a user revokes access, all associated financial data is deleted immediately — accounts, transaction history, and consent records are permanently removed at the moment of disconnection. API request logs are retained for 2 years for security and audit purposes, then deleted automatically.

Monitoring & Incident Response

OpenDinar logs every API request — endpoint, status code, timestamp, and API key — giving us a full audit trail of all activity. The server runs under PM2, a process manager that automatically restarts the service if it crashes and keeps logs for post-incident review.

We have a written incident response plan covering detection, containment, assessment, notification, recovery, and post-mortem review. In the event of a confirmed security incident, affected developers will be notified by email within 72 hours of discovery — as required by Serbian ZZPL (Article 53) and in line with GDPR notification standards. We intend to publish incident postmortems for significant events.

Infrastructure

OpenDinar's API infrastructure is hosted on DigitalOcean, a SOC 2 Type II certified cloud provider. Key infrastructure security properties include:

• Per-tenant data isolation — each developer's data is logically isolated at the database level
• Backups — DigitalOcean takes encrypted weekly snapshots of the server. Automated daily database backups with point-in-time recovery are on the pre-launch checklist.
• Encrypted block storage — the database lives on a dedicated encrypted volume (AES-256), separate from the server's local disk
• Principle of least privilege — internal team members only have access to systems required for their role
• Dependency management — third-party dependencies are reviewed and updated on a regular schedule; automated vulnerability scanning on every change is part of the pre-launch work below

Compliance & Certifications

OpenDinar operates in alignment with EU data protection standards, as Serbia continues harmonisation with GDPR under the Law on Personal Data Protection (Zakon o zaštiti podataka o ličnosti). Our data handling practices are built to meet these requirements from day one.

OpenDinar does not hold any third-party security certification today. These are the certifications we intend to pursue, with our current target dates:

Before We Go Live

OpenDinar runs on simulated data today, and we would rather tell you what is still being built than let you assume it is already finished. Every item below is committed work that will be completed and independently reviewed before the first real bank account is ever connected.

• Hash-only API key storage — removing full-key storage from the database entirely, so a key exists in readable form only at the moment we show it to you.
• Rate limiting across every banking endpoint — extending the limits already in place on account and authentication endpoints to the full API surface.
• Encrypted store for bank credentials — a dedicated encrypted vault for the access tokens real banks will issue us, separate from ordinary application data.
• Field-level encryption — encrypting IBANs, account holder names, and balances individually inside the database, on top of the encrypted volume they already sit on.
• PostgreSQL with point-in-time recovery — moving off SQLite to a managed database with automated daily backups we restore-test on a schedule.
• Detailed access audit trail — recording not just that a request happened, but exactly which data was returned, to whom, and when, as financial regulators expect.
• Infrastructure hardening — locking network access down to only the ports the service needs, and key-only administrative access.
• Monitoring and alerting — automated detection and paging on anomalies, rather than reviewing logs after the fact.
• Independent security review — an external assessment of the platform before launch, followed by the certification programme described above.

Your Users' Rights

OpenDinar supports your users' data rights under applicable law. Users whose financial data is processed through OpenDinar can:

• Access — request a copy of the data we hold about them
• Correction — request correction of inaccurate data
• Deletion — request deletion of all data associated with their bank connections
• Portability — receive their data in a structured, machine-readable format
• Objection — object to processing in certain circumstances

Data subject requests can be submitted by contacting privacy@opendinar.com. We respond to all requests within 30 days.

For full details on how personal data is collected, used, and protected, see our Privacy Policy.

Report a Security Issue

If you believe you have found a security vulnerability in OpenDinar's API, infrastructure, or website, we want to hear from you. We take all reports seriously and will respond promptly.

We do not currently operate a formal bug bounty programme, but we acknowledge all valid reports and will credit researchers who disclose responsibly.