Security Engineer

We move money across borders in real time. That means every request is a promise, and every promise can be attacked.

We're looking for a Security Engineer who thinks like an attacker in the morning and a defender at night, someone who doesn't just secure systems, but builds environments where bad actors get bored and leave.

This is not a compliance role. It's not paperwork security. It's hands-on, system-level defense of real infrastructure under real pressure, including live USDT transactions.

If you prefer dashboards and policy documents over logs and terminals, this isn't it. If you like finding the crack before it becomes a headline, keep reading.

What you'll work on

You'll own the security posture of systems that handle authentication, payments, crypto transfers, and sensitive user operations. You'll sit close to engineering, not behind an approval layer.

Your job is to make sure that even when things go wrong, and they will, nothing important breaks.

Core skills

1. Linux & server security

You should be able to make a fresh server safe enough to sleep next to.

• Hardening Ubuntu/Debian systems from first boot
• SSH security — keys, disabling root login, fail2ban
• Firewall configuration (UFW/iptables)
• File permissions, process management, system logs
• Detecting suspicious processes and abnormal system behavior

 2. Cloud security posture

We run on cloud infrastructure. Misconfigured IAM, exposed storage buckets, and overpermissioned services are real attack surfaces.

• AWS or GCP IAM, least privilege, role scoping, audit trails
• Storage and secrets hygiene (no credentials in environment variables, no public buckets)
• Security group and network configuration
• Cloud-native logging and alerting (CloudTrail, GuardDuty, or equivalent)

3. Web application security

We care about how systems actually break in the wild:

• SQL injection, XSS (stored and reflected), CSRF
• Authentication bypass and session hijacking
• Rate limiting abuse, login, OTP, account creation, APIs
• Bonus: you've fixed real vulnerabilities in live systems, not just read about them

4. API security

Our APIs are the backbone of the product; they move money, trigger transfers, and touch wallets. You need to think in abuse paths, not just endpoints.

• API authentication, JWT, session tokens, API keys
• Replay attack prevention and request signing (HMAC)
• Rate limiting strategy for financial endpoints
• Protecting transfer, conversion, and wallet endpoints from manipulation

5. Crypto & USDT transaction risk

USDT transfers are live and core to our product. Irreversible transactions with no chargebacks attract sophisticated fraud. You need to understand the terrain.

• Common attack patterns on crypto payment flows
• Transaction spoofing and double-spend awareness
• Wallet-level abuse patterns, bot creation, draining, and round-tripping
• Secure handling of keys, wallet addresses, and transaction state

6. Backend security awareness

You don't need to be a backend engineer, but you need to understand the terrain:

• Where security bugs hide in applications
• How to read logs and trace unusual behavior back to the root cause
• How interpreted-language stacks behave under load and attack

If logs feel like noise to you, this won't work.

7. Incident response

When something looks wrong, you don't theorize, you act.

• Detect breaches and anomalies quickly
• Contain attacks, block traffic, isolate components
• Investigate logs and reconstruct what happened
• Communicate what's happening in plain, clear terms

Speed and clarity matter more than elegance.

Nice to have

• Penetration testing tools, Burp Suite, Nmap, etc.
• Familiarity with fintech fraud patterns, bot signups, referral abuse, and wallet manipulation
• Third-party and supply chain risk awareness, payment partners, KYC vendors, SDKs
• Password hashing, encryption at rest, and secure storage patterns

What we're looking for

Calm under pressure. Security incidents are rarely polite. You'll deal with urgency and uncertainty simultaneously. We need someone who stays steady when things are actively going wrong.

Detail-oriented by default. A misplaced log entry or a slightly odd pattern can be the difference between normal traffic and an active attack. You should naturally notice things others skip.

Practical, not academic. We don't need textbook security. We need people who say: "Here's how this actually gets exploited in the real world", not "In theory, this is mitigated by…"

Ownership, not assistance. You don't assist security. You own it. When something breaks, the instinct should be: I need to understand this and fix it, not *that's someone else's problem.

Low ego, high alertness. The best security engineers are not loud. They're observant. We value people who learn fast, admit gaps quickly, fix quietly, and stay focused on outcomes.

How we'll assess you

We'll give you this scenario:

> Our system suddenly shows repeated failed login attempts and unusual spikes in wallet creation. What do you do in the first 60 minutes?

We're not building a system that is secure by policy. We're building one that is secure by design, pressure-tested by reality, and quietly resilient when things get loud.

To apply, send in your assessment and resume.