Secure Exchange Architecture with Counterparties: MFT, API

Where risks start in external exchange

Risks don’t appear because of a “bad internet”; they appear when data leaves your organization and ends up in other people’s hands, systems and processes. Once an external counterparty is in the chain, you lose control over part of the path: who accessed the data, where the file was stored, who forwarded the email, and how their accounts and archives are protected.

Three channels are usually involved in external exchange. Files are shared via shared folders, SFTP/FTPS, ‘‘temporary’’ file-sharing sites and messengers. APIs are used for system integrations (orders, statuses, directories). Email remains the most common way to send acts, registries, invoices and exports because “it’s faster”.

A counterparty isn’t just a supplier or a client. It can be an outsourced contractor, a bank, a government body, an educational institution, or any third-party IT platform where the counterparty stores your data. These relationships are riskier: differing security maturity levels, different administrators, and different requirements for storage and logs.

Most common leaks or tampering involve personal and HR exports, financial documents (payment registries, invoices, acts), commercial files (price lists, specifications, contracts), technical data (logs, dumps, configurations), and credentials in emails and attachments (passwords, keys, tokens).

A typical problem: exchange is built by habit, gradually adding exceptions. For an urgent export they open server access “for a couple of days”, send a file from personal mail, then forget to revoke access. These create ‘‘holes’’ that don’t show on diagrams but work in practice.

Why doesn’t "just VPN" solve it? VPN encrypts the channel but doesn’t make the exchange manageable. It doesn’t answer security questions: who specifically sent the file, who downloaded it, what was transferred, where it’s recorded, how fast you can find an incident and prove data immutability. Moreover, VPN often becomes a ‘‘network extension’’ that accidentally grants external users more access than needed.

The starting point is simple: external channels will always exist. So you need control over transmission, identification and clear audit, not just a ‘‘secure tunnel’’.

Roles of MFT, API gateway and mail gateways in plain language

When talking about secure exchange architecture with counterparties, three different tasks are often mixed: file transfer, API calls and business email. Each task has its own rules. Trying to put everything on one server usually ends in gray areas where it’s unclear who sent what, who authorized it and where it’s recorded.

MFT (managed file transfer) is for when you transfer files: registries, exports, scans, reports. Its strength is manageability: it queues files, retries delivery on failure, records confirmations and provides a clear history for each file. For security teams this answers quickly: when did it leave, who sent it, did it arrive, was it altered in transit.

An API gateway solves a different problem: secure entry to your services via APIs. It doesn’t run business logic but applies rules at the boundary. It verifies who is calling and what they can do, limits request rates, controls methods and formats. This reduces the risk of service overload, control bypass and exposure of extra data.

A mail gateway is for emails and attachments, where the main risks are phishing, malicious attachments and leaks via ‘‘ordinary mail’’. It inspects content, applies policies (for example, blocking certain data types), supports encryption and applies domain-specific rules for counterparties.

A useful logic:

• MFT is responsible for the file as an object and provable delivery.
• API gateway is responsible for the request as an action and access control at the entry.
• Mail gateway is responsible for the message as a channel and protecting people and endpoints.

Why is it dangerous to mix all in one place without boundaries? Because files, APIs and mail have different policies, logs and trust levels. If one shared server handles mail, files and APIs, compromise of one component opens the door to all channels. Also, audit becomes unclear: logs get fragmented or ‘‘glued’’ so security can’t reconstruct the event chain.

In practice it’s better for each channel to have its own control point and its own logs, and for security to be able to correlate events by identifiers (counterparty, document, time, delivery result). That makes protection and verification simpler.

Threat model and trust boundaries

To avoid turning the exchange architecture into a patchwork of random protections, start with a simple threat model. It’s not for paperwork—it's to make clear what you protect, from whom, and where the boundary after which trust ends.

What we consider assets and why it matters

Assets aren’t only files or API requests. External exchange often breaks through ‘‘auxiliary’’ things that are remembered last.

Typical assets include data (files, attachments, API payloads and metadata like contract numbers), accounts and permissions (service users, groups, roles, tokens), cryptography (keys, certificates, secrets, HSMs or secret stores), logs and traces (MFT, API gateway, mail gateway logs, SIEM events), and configurations (routes, policies, filtering rules, partner lists).

Agree on priorities early. For some processes confidentiality is paramount; for others integrity and non-repudiation; and for others availability. Financial exchange usually demands integrity and provability; mass notifications prioritize availability.

Who attacks and where trust ends

The adversary isn’t always an external hacker. In B2B more common scenarios are: a partner’s compromised email, a contractor’s faulty script, a token leaked in logs.

Useful attacker roles:

• external attacker without legitimate access;
• internal employee with excessive rights or an accidental action;
• contractor or counterparty whose credentials were compromised;
• administrator or engineer who changes rules without approval.

Then draw trust boundaries. Minimum set: external zone (internet and partner networks), DMZ (public reception and filtering points), internal contour (services and storages), and a separate management zone (admin access, CI/CD, secret stores). Every transition across a boundary should have explicit control: authentication, format validation, command and route restrictions, and audit logging.

Example: a hospital sends a services registry to a counterparty. The file passes through the DMZ where source and data type are verified, then it enters the internal contour only after signature and routing checks. Signing keys and logs are in the management zone with no direct DMZ access. That makes trust boundaries clear and auditable.

If you implement this as an integrator (for example, on projects by GSE.kz), it’s easier to discuss with security not ‘‘which product to install’’ but ‘‘which boundary we close and which controls we apply’’.

Reference data flow scheme without unnecessary port forwards

A good secure exchange architecture starts with one rule: different exchange types should not use the same channel. Files have their rules (size, retries, integrity checks), APIs have theirs (rate, authorization, limits), and mail has its own (attachments, anti-spam, DMARC). Mixing them creates bypass routes and ‘‘temporary’’ forwards into the internal network.

How to separate flows and where to place components

A typical skeleton: the external side talks only to the perimeter, and internal systems see only strictly designated internal connectors.

• DMZ (perimeter): MFT gateway, API gateway, mail gateway (or its external part), and content inspection services (AV, sandbox, DLP as needed).
• Internal contour: business systems (ERP, CRM, EDI, storages), queues/buses and dedicated connectors to MFT and API gateway.

Example: a counterparty sends a registry file. It lands on the MFT in the DMZ, passes checks, is placed into the correct folder, and only then is picked up by an internal connector to the internal store. The counterparty never gets a direct route to a file server or database.

Control points that close the ‘‘holes’’

In this scheme, designate control points in advance rather than adding them later:

• authentication and partner binding: separate accounts, certificates or keys—no shared logins;
• content checks at ingress: antivirus, file-type validation, basic DLP rules for sensitive data;
• allow-list routing: which partners can access which services and in which formats;
• ban direct connections: a counterparty should not access internal subnets via VPN ‘‘for convenience’’ or via temporarily opened ports.

A practical test: if you can open a port from an internal system to the outside, you’re already building a bypass. Better to keep one managed entry via MFT/API gateway/mail gateway, then route inward only via short, documented links.

Step-by-step: how to build a secure scheme from scratch

Start not with choosing a product box, but with a clear picture: what data leaves, who owns it, and what happens if the channel fails or is compromised. Then the secure exchange architecture becomes understandable to IT and security alike.

Steps you shouldn’t skip

1. Inventory integrations. For each export or request record the data owner, data type (personal, financial, internal), frequency, acceptable delay, retention, and who confirms successful delivery.

2. Choose the channel by scenario. MFT suits batch and large-volume exchanges. API via API gateway fits interactive request–response and strict method control. Email is for human-involved processes but only with clear attachment controls.

3. Design segmentation. Separate zones so external connections don’t have direct paths to internal systems. The external side sees only the perimeter (gateways); internal exchange goes via strictly defined directions and ports. Treat any ‘‘temporary forward’’ as an incident, not a norm.

Then define policies in a simple format: who can send or request what (data types), where (destination), when (windows, frequency), and what confirmation is required (receipt, signature, checksum, retry).

4. Configure control points. In MFT: intake rules, format checks, quarantine and delivery confirmation. In API gateway: authentication, rate limits, request schemas and filtering. In mail gateway: attachment policies, anti-phishing and blocking of outbound transfer for certain data classes.

Step 5: testing that actually finds ‘‘holes’’

Test not only the successful path but also bad conditions:

• invalid credentials, expired keys, attempts to access others’ resources;
• corrupted file, bad signature, sender spoofing;
• duplicate deliveries (idempotency);
• node failures (gateway, channel, queue) and proper recovery;
• peak loads and limit enforcement without service collapse.

Example: a hospital sends a daily registry to an insurer via MFT in the DMZ. The file is validated for format and signature, then moved to the internal system by an allowed route. A delivery receipt with a transfer ID returns via the same channel. If the signature is invalid, the file goes to quarantine and an audit record is created.

Access and identification: who can send and receive

Without clear access rules, holes aren’t caused by encryption but by people and habits: shared logins, forgotten tokens, excessive rights ‘‘just in case’’. Start with a simple rule: each counterparty is a separate entity in accounts, policies and logs.

The single principle is least privilege. For MFT, create separate service accounts per counterparty and, if possible, per exchange type (e.g., "receive acts" vs "send reports"). For API gateway, issue distinct client credentials and limited scopes/roles per external app. For mail gateway, create trusted domains and tailored policies—don’t use a ‘‘allow everything’’ mode.

Treat shared logins and ‘‘one key for all’’ as an incident that hasn’t happened yet. If two people at a counterparty need access, create two accounts instead of a shared one. That way a single termination won’t stop the whole exchange.

Use MFA where appropriate: for MFT administrators, web consoles, and manual operations. For machine access, prefer secret rotation and short-lived tokens plus a clear reissuance process.

Define how you restrict access so it matches the data flow: by IPs and subnets (partner and your outbound addresses), by time windows, by methods (upload only vs download only), by sizes and types (limits, banned formats), and by frequency (protection against brute force and noisy requests).

Example: a government body receives reports from suppliers. Each supplier gets access only to its upload folder and upload rights. In API gateway, each supplier receives a key valid for a single endpoint. Mail gateway accepts mail only from agreed domains and blocks unusual attachment types. Security then has a clear picture: who sent, where, how identity was proven and what was permitted.

Encryption, signing and key management

In a secure exchange architecture, encryption and signing should be layered, not a single checkbox. Channel protection secures transport, data encryption protects content if misrouted or stored in the wrong place, and signatures provide integrity and audit evidence.

Channel encryption: TLS without self-deception

TLS helps only if you actually verify who you connected to. The most common mistake is accepting any certificate and assuming everything’s fine.

Check the basics:

• enable certificate chain and hostname validation;
• forbid outdated protocols and weak ciphers;
• configure mutual TLS (mTLS) when counterparties are few and risk is high;
• avoid shared certificates across services/environments (separate test and prod);
• log TLS events (validation errors, certificate changes).

Data encryption and signing: what to encrypt and where to sign

For email choose S/MIME or PGP so encryption is end-to-end at the message level, not only between mail servers. For file exchange via MFT consider encrypting the file before sending and encrypting MFT storage if temporary copies and queues exist.

Signing should be done by the sender before transfer so the recipient can verify the file wasn’t altered. At the perimeter (mail gateway, MFT, API gateway) verify signatures automatically and log the result: is the signature valid, who signed it, which certificate and which policy applied. That simplifies incident analysis.

Example: a hospital encrypts and signs a registry before sending. Even if the message is forwarded to the wrong recipient or stored in a shared folder, without the key the file is useless and the signature proves no tampering.

Treat key management as a process: store keys in a secure repository with role-based access, rotate on schedule and on personnel changes, have revocation and incident plans, split responsibilities (key owner, operator, security), ensure backups so a key doesn’t disappear with a person.

In critical environments (government, finance) pre-agree who issues and trusts certificates and how verification and logging look on each node.

Audit and logs: make them useful for security

Logs for external exchange aren’t for show. They must quickly answer three questions: who performed the action, what happened, and where it propagated. This is vital because multiple channels exist (MFT, API gateway, mail) and different teams own each part.

Start with a set of events that must always be logged—not only successful transfers but suspicious attempts and admin changes. Any action changing access or routing should leave a trace.

At minimum, record:

• authentication and authorization (logins, failures, expired tokens, locks);
• data transfers (start/finish, volume, hash/checksum, delivery errors);
• suspicious events (limit breaches, frequent retries);
• administration (policy, route, certificate and recipient list changes);
• access to logs (who viewed, exported, or changed logging settings).

To avoid time-based stitching, introduce a correlation ID. It should appear at the initial ingress (API gateway, MFT, mail gateway) and be passed on—in headers, MFT job metadata, and target system records. One ID should show the request passed checks, the file scanned by AV, policies applied, and final delivery.

Normalize logs so SIEMs don’t drown in noise. Map events to common fields: timestamp (with timezone), source system, user/service, counterparty, channel (API/MFT/mail), action, result, failure reason, address and device, operation ID, object (file/endpoint), and data classification.

Retention matters: set timelines (for example, 90 days online, 1–3 years archived), ensure immutability (WORM or equivalent) and separate rights. Exchange admins shouldn’t be able to erase traces; security should have read/export per rules.

Regular reporting helps catch issues before incidents: top failure reasons, new counterparties and channels, policy changes, transfers with volume deviations, attempts to access blocked resources, and gaps in logging coverage.

Common mistakes that create ‘‘holes’’

Even with MFT, API gateway and mail gateway, problems usually come from small ‘‘conveniences’’. The architecture looks correct on paper but in reality is bypassed in 2–3 steps.

Where security most often breaks

The most frequent error is a ‘‘temporary’’ direct path into internal systems. To speed deployment people open a port straight to a file resource or an internal API, bypassing MFT or gateway. That exception is then forgotten and firewall rules remain for years.

Another danger is disabling certificate validation ‘‘for a few days’’ while a partner configures TLS. The exception persists and man-in-the-middle becomes possible.

There are errors that seem unrelated to security but hurt reliability and investigations. Without receipts and retries a file can quietly vanish: the network blinked, the connection dropped, and the sender saw ‘‘success’’. A week later a dispute arises and there is no proof.

Mixing test and production is another source of holes. If test partners and production counterparts share the same contour, you can accidentally send real data to a test system, or test credentials might access production routes.

Typical manifestations:

• ‘‘We made a certificate exception because it wouldn’t connect,’’ and it remained after pilot.
• ‘‘For convenience’’ a direct internal entry was opened because MFT was slower.
• No receipts or retries, so missing files are only found by complaint.
• One contour for test and prod, differing only by folder or prefix.
• Logs exist everywhere but can’t be stitched into one chain.

To close these holes, check simple things: is there a single entry point per exchange type without bypasses; is certificate validation strict and is exception approval documented; are deliveries confirmed and retried; are test and prod separated by networks, credentials and keys; can you answer ‘‘who sent what, where, when and how it finished’’ by one operation ID.

Short checklist and next steps

Before launching external exchange, do a quick check. It reveals holes before a pilot and gives security clear answers: who, what and how.

Pre-start checklist

Confirm these basics:

• APIs have a single entry via API gateway, and files and mail use separate channels (MFT and mail gateway) with no direct internal forwards.
• Each counterparty has separate credentials, roles and limits (by volume, frequency, allowed methods and directions).
• Where needed, encryption and signing are enforced technically, not left to agreements.
• Logs are collected centrally and allow reconstructing the operation chain: who initiated, what was sent, which component handled it, result and error codes.
• There is a procedure for failures, suspected key compromise, disputed deliveries or denial of sending.

If you’re unsure about any of these, stop and resolve them before scaling exchange to all counterparties.

30–60 day rollout plan

Timelines depend on the number of counterparties and security requirements, but a working frame is:

• 1–2 weeks: inventory flows, classify data, agree encryption and log rules.
• 2–4 weeks: pilot with 1–2 counterparties, configure roles, limits, log formats and alerts.
• 4–6 weeks: approve regulations (keys, access, incidents), train owners, go live.
• 6–8 weeks: onboard remaining counterparties, test resilience, monthly log reviews with security.

If you need a partner for implementation, involve a system integrator who covers not only component installation but rules, audit and support. For example, GSE.kz (gse.kz) operates as both vendor and integrator and can help build, implement and support such a scheme, including 24/7 technical support through their service network.