Vendor and scheme readinessجاهزية المورّدين والشبكات

A vendor is a company you buy part of your product from: identity verification, card processing, hosting. A scheme is whoever sets the rules everybody follows, like mada or Visa.

Your company's name remains on the customer complaint even when another company's system failed.

If the vendor broke, why am I the one carrying it?

The feeling is fair. You bought a service from a specialist company, paid for it, and they went down, not you. So why does the blame land on you?

Because the customer did not contract with your vendor. They contracted with you.

When a user opens your app and cannot pay, they do not know an identity provider in another city is the cause. They see your name on the screen, they write your name in the complaint, and they carry your name into their review.

The same applies at the regulator, and more strictly. The licence is in your name and the obligation is yours. Saying the vendor failed will not be accepted, because choosing and monitoring that vendor was part of your responsibility in the first place.

The rule is that you outsource work and never responsibility.

Something practical follows. It is not enough to ask a vendor whether they are reliable. You need to know in advance what you do when they break, not if. What is your message to the customer? How long do you wait before switching to an alternative? Do you have an alternative at all, or does every flow depend on one provider?

A company that answers those questions on the day of the outage loses hours. One that answered them beforehand loses minutes.

Outsource work, not responsibility

A supplier may provide identity checks, card processing, or cloud storage. The contract does not transfer your duty to customers and regulators. If that supplier leaks data or stops payments, the licence holder must explain selection, oversight, and response.

Map the service, data, and money each supplier touches. An email provider differs from a bank holding customer balances. Classify whether failure could stop a licensed service, expose sensitive data, or block ledger access.

Inspect evidence, not answers

Due diligence (العناية الواجبة) means examining a supplier before dependence and preserving the record. Request ownership, licences, policies, test results, material incidents, and continuity plans. A completed questionnaire is not evidence by itself.

If a supplier claims encryption, ask where, who controls keys, how they rotate, and whether backups are covered. Read penetration-test scope, date, exclusions, and proof that findings closed.

Investigate subcontractors. Data may pass to a fourth company in another country. Contracts need a list, change notification, and objection rights where required.

Read SOC 2 (تقرير SOC 2) carefully

A SOC 2 report gives an independent auditor's view of service-company controls. Type I covers control design on one date. Type II covers operation over a period.

Type II is more useful for continuing reliance, but read its period, scope, exclusions, and findings. It may cover an HR product rather than the payment platform you use.

Find complementary controls expected from customers. The report may assume you enable multifactor authentication and review users. Supplier controls do not compensate if you ignore those duties.

Calculate concentration risk (مخاطر التركّز)

Concentration risk means several dependencies can fail together. Three vendors operating in one cloud region are diverse only on invoices.

Map each critical service down to cloud, region, network, data subcontractor, and sponsor bank. Compare chains for shared points.

A backup vendor helps only if switching is tested. Activation may take a week or use incompatible data. Keep permissions, controls, and rehearsed procedures ready.

Put waiting time in the plan

Card certification or bank approval can take months because of queues and test cycles. Additional engineers cannot shorten another organisation's calendar.

Start early. Record requirements, versions, test windows, and approvers. Allow time for a failed test. Do not promise a market date that depends on first-time acceptance.

Test realistic declines, limits, and settlement files. A sandbox that approves everything proves little.

Write an operable contract

Specify incident notification, data ownership, processing location, audit rights, service objectives, support, remediation, and termination. Make commitments measurable.

Assign reconciliation, refunds, and customer complaints explicitly. Otherwise each side may assume the other watches pending operations.

Do not accept an availability number without its measurement and exclusions. A supplier may exclude maintenance and all partner failures, leaving a high but meaningless percentage.

Monitor after signing

Due diligence does not end at purchase. Review performance, incidents, reports, and security or financial changes. Obtain current SOC 2 and penetration evidence.

Track customer symptoms such as verification failures and payment delay, not only API availability. A successful response may hide a growing internal queue.

Rehearse a joint incident. Know who contacts the supplier, what data may be shared, and when management or regulators are involved.

Write the exit before entry

An exit plan covers an alternative or temporary operation, data migration, deletion, fund settlement, and customer communication. Do not wait until the relationship has deteriorated.

Define export format, frequency, transfer cost, and retention. Test a sample restore with an alternative. Proprietary data formats can lock the company in.

Exit time differs. An email vendor may change in days; a sponsor bank or card scheme can need months and new certification.

Third-party dependence is safe only when boundaries, evidence, common failures, and exit routes are known. The goal is not to build everything. It is to justify the choice, prove oversight, and protect customers when a partner fails.