A Good Bank Screens the Payment. Does That Remove the Company’s Responsibility?

Why company-side and bank-side controls answer different questions in the maritime crew-payment workflow.

A reasonable question often comes up when sanctions screening is discussed with payroll and finance teams:

“Doesn’t our bank already screen every payment?”

A reputable international bank should have sanctions controls. It may screen parties named in a payment, examine transaction information, apply its own risk rules and pause or reject an instruction that requires further investigation.

So why should a ship-management or crewing company screen the payment earlier?

At first glance, company-side screening can look like duplicate work. One more system checking a name that another, much larger system will check later.

It can feel a little like assigning two people to stand beside the same door, each asking to see the same invitation.

But the company and the bank are not really guarding the same door.

The bank is deciding whether it can process the payment through its systems.

The company is deciding whether it has enough current information to release the instruction through its own payment process—and whether it can show what was checked if a question appears later.

Before we get to the difference between those two controls, however, there is a more basic objection to address.

“Why question a crew member’s payment at all?”

A payroll, crewing or finance person could reasonably say:

“We trust our crew. Why would a crew member risk an entire career by knowingly directing wages to a sanctioned person?”

That is a fair question.

Company-side screening should not begin from the assumption that crew members are dishonest or that an ordinary allotment is suspicious.

A crew member may have no reason to know that a beneficiary, receiving bank or another relevant party has become subject to sanctions. The allotment may have been established years earlier. Sanctions information may have changed since then. A name that produced no candidate match before may produce one today because a record or additional identifier has been added.

None of this requires bad intent from the crew member.

The company is also not being asked to investigate how every crew member chooses to use their wages. The broad purpose is already understood: the company is carrying out an authorised allotment instruction.

The narrower operational question is whether the company has enough current information about the beneficiary and receiving bank to release that instruction through its own accounts and payment process.

That distinction matters.

Trust in the crew member and current information about the payment are not opposing ideas. One does not have to be withdrawn before the other becomes useful.

“We have done this for decades. Why fix what is not broken?”

This may be the next and perhaps stronger objection:

“We have managed crew payments for years—or decades—and have never encountered a sanctions incident. Why add more work now?”

A long incident-free history is meaningful. It suggests that the existing payment process has generally worked.

But it does not necessarily show that the underlying risk has remained unchanged.

Sanctions regimes, designated parties, payment routes and the information expected within payment instructions continue to change. A question may also have been identified and handled downstream by a bank without becoming visible as a company-side control issue.

The answer is not to place maximum compliance machinery around every ordinary allotment payment.

A company managing a small number of crew should not automatically need the same process as one managing thousands of crew-linked payment accounts across multiple entities, banks and jurisdictions.

The control should be proportionate to the company’s scale, exposure and existing workflow.

More importantly, it should direct human attention towards the relatively small number of records that genuinely require it. If a new control merely gives payroll another large spreadsheet to inspect every payment morning, the resistance to it would be entirely understandable.

The objective is not to distrust the crew or manufacture more administrative work.

It is to avoid making trust in the crew perform a job that current payment data and appropriate company controls are better suited to perform.

That brings us back to the bank.

“If the bank screens the payment, why should we screen it too?”

Bank screening is an important downstream control.

Banks process payments across currencies, jurisdictions and financial networks. Their compliance systems can identify questions that the company missed, could not identify or did not possess enough information to investigate.

Company-side screening does not replace this control. Nor can it guarantee that a bank will accept a payment.

The practical difficulty is that the bank usually encounters the payment instruction near the end of the company’s internal workflow.

By then:

• payroll may already have been calculated and approved;
• allotment payments may already have been added to the current payment draft;
• the payment draft may have been reviewed and approved;
• the bank file may have been generated; and
• the payment instructions may already have been submitted.

If the bank raises a question at that point, its control may be working exactly as intended.

The company still has a late operational problem.

Someone must retrieve the crew and beneficiary records, confirm the bank details, understand the relationship, find any supporting information and reconstruct whatever earlier review took place.

Ideally, all of this happens before the payment deadline begins tapping its watch.

The difference is not that one control is good and the other is bad.

The difference is timing, context and ownership of the decision.

“Wasn’t this beneficiary already approved?”

Consider an ordinary continuing crew allotment.

The crew member supplied the beneficiary and bank details eighteen months ago. The allotment was administratively reviewed, entered into the crew-management system and used in several payment cycles.

Nothing has recently changed in the stored record.

Does that mean sanctions screening was performed when the allotment was approved?

Perhaps. But perhaps not.

In some organisations, “approved” may mean that the account details were complete, the crew member’s request was authorised and the allotment could be processed administratively.

It does not automatically tell us:

• whether sanctions screening took place;
• which beneficiary and bank details were checked;
• which sanctions sources were used;
• whether a possible match appeared;
• who reviewed it; or
• what conclusion was reached.

Administrative approval and sanctions review are not the same decision, even when they happen at approximately the same time.

This matters because sanctions information changes.

A beneficiary or receiving bank that produced no candidate match eighteen months ago may produce one today. A transliteration may now identify a different candidate. A sanctions record may have gained new identifiers. The company’s own payment or risk policy may also have changed.

A later question does not automatically mean the earlier decision was wrong.

It means the current payment should be considered using the information available now.

“Approved before” is useful history.

It should not be mistaken for a green tick with lifetime tenure.

“What can the company know that the bank may not?”

The bank may know a great deal about its customer and the payment travelling through its systems.

But it does not necessarily possess the company’s complete operational context.

The maritime company may know:

• who the crew member is;
• how the beneficiary is connected to the crew member;
• when the beneficiary or bank details were supplied;
• whether the account was recently changed;
• whether a shortened, translated or transliterated name was used;
• what supporting information was collected;
• whether a similar candidate appeared previously; and
• why an authorised reviewer cleared or escalated it.

The beneficiary may be a family member, but not necessarily. Crew allotments may also be directed to creditors, friends, institutions, charities, representatives or other parties.

The company is normally better placed to understand that relationship.

A payment message cannot carry the company’s entire relationship history. It has not attended the payroll meeting, read the email correcting the beneficiary’s name or seen that an account change arrived after the normal cut-off.

If the first meaningful question appears only after submission, the company must reconstruct this context at the least convenient moment.

Nothing has necessarily failed inside the bank.

The question was simply raised very late in the company’s own workflow.

“Isn’t this still duplicate screening?”

It can be.

Running identical data through the same kind of check twice, at almost the same moment, without preserving or connecting the results may add activity without adding much protection.

That is duplication.

Layered controls are different because they operate at different points and reduce different risks.

One possible company-side model is to:

1. screen beneficiary and receiving-bank details when an allotment is created or materially changed;
2. preserve the result and any human review connected to that version of the details;
3. check the resulting payment again when it is prepared within the current payment draft, using current sanctions data and the company’s policy;
4. hold or escalate unresolved exceptions before payment-draft approval and bank-file submission; and
5. allow the bank to perform its independent downstream controls as usual.

The exact process will vary. A smaller crewing company may use a relatively simple procedure. A company managing thousands of crew-linked payment accounts may need automation, structured review queues and policy-driven rescreening.

The objective is not to turn the payroll department into a smaller, slightly more tired version of the bank.

It is to ask the relevant question while there is still time to act on the answer.

Where Should Sanctions Screening Fit in the Maritime Crew Payroll and Payments Workflow?

“Does using a bank transfer the company’s responsibility?”

There is no single worldwide rule requiring every maritime company to use the same screening product, check the same lists at the same moment or follow one prescribed workflow.

The applicable obligations and appropriate controls can depend on the company, jurisdictions, parties, currencies, banks, payment routes and underlying activity.

Official guidance generally reflects this risk-based approach.

The US Treasury’s Framework for OFAC Compliance Commitments says an organisation’s sanctions-compliance programme should be based on its particular risks and includes internal controls, testing, training and management commitment. OFAC’s more recent guidance for the maritime shipping industry recommends robust internal sanctions-compliance controls for maritime stakeholders.

The UK government’s starter guide to sanctions says sanctions legislation does not prescribe one particular due-diligence method. It nevertheless advises businesses to examine whom they are dealing with and to repeat due diligence for established counterparties because risks may change.

The European Commission’s guidance for EU operators similarly says operators are expected to maintain due-diligence measures for relevant activities that may fall within EU sanctions.

None of this creates one universal maritime-payroll screening formula.

It does point in a consistent operational direction: a company should understand its own exposure and adopt controls proportionate to that exposure. The existence of a bank later in the payment chain does not, by itself, document how the company decided it was comfortable releasing the payment.

The bank remains responsible for its decision.

The company remains responsible for its own.

A related signal: better payment data is moving upstream

There is another change worth noting because it illustrates the growing importance of the data supplied earlier in the payment chain.

From 14 November 2026, SWIFT’s CBPR+ requirements will no longer support fully unstructured postal addresses. Town and country information must be provided in designated fields, at a minimum, for parties and agents in the affected payment messages, subject to specific exceptions such as the continued use of a BIC alone for an agent.

Payments using unsupported unstructured addresses may be rejected at the network level. SWIFT explains that structured address information improves payment-data quality, straight-through processing, transparency and compliance screening. SWIFT’s November 2026 guidance provides the detailed scope.

This is a payment-messaging requirement. It is not a new rule ordering every maritime company to introduce a particular sanctions-screening workflow.

But it is a useful signal.

Banks and payment networks increasingly need clearer, structured information about the parties to a payment. That information often originates in the company’s beneficiary, bank-master, payroll or crew-management records.

Better downstream controls depend, at least partly, on better upstream data.

The detailed SWIFT implications deserve a separate article. Otherwise this one will soon need its own project manager and refreshments.

“What happens if one payment produces a possible match?”

A possible match does not mean that the beneficiary or bank is sanctioned.

It means that someone needs to investigate.

A useful upstream control should allow the affected payment instruction to be separated for review while the company determines what its policy permits for the rest of the payment draft.

The reviewer may need to compare:

• the supplied beneficiary or bank name;
• dates of birth, addresses, nationalities or countries where available;
• original-script or transliterated names;
• the matched sanctions record and its identifiers;
• previous screening results;
• any previous human resolution; and
• what has changed since that earlier decision.

Who performs the first review will vary. It may be payroll, finance, crewing, compliance or a combination of them.

That ownership should be decided before an exception appears—not invented while the bank-file submission window is closing.

The aim is not to pretend that every possible match can be resolved automatically. It is to give the responsible people the relevant information, decision history and time to investigate it.

“Do we need to recheck everything manually every month?”

Not necessarily.

For a company managing hundreds or thousands of payment accounts, repeatedly reopening every record would create another operational problem.

A more useful approach is to retain a known screening state containing information such as:

• when the subject was screened;
• which beneficiary and bank details were checked;
• which sanctions sources or data version were used;
• what candidates were returned;
• whether the account data, source coverage or policy later changed;
• who reviewed an exception;
• what decision was made; and
• why that decision was considered reasonable.

Rescreening can then be triggered according to the company’s policy—for example, by a material account change, updated sanctions information, preparation of a current payment or a combination of these events.

Previous human resolutions can be retained. Unchanged candidates need not always return looking pleased to meet everyone again.

But a genuinely new candidate, new identifier or material change should not be hidden merely because something similar was cleared before.

The goal is neither a permanent green tick nor permanent manual rechecking.

It is a current, explainable decision.

“Where would CrewPayScan fit?”

CrewPayScan is intended to sit alongside the company’s existing crew-management, payroll and payments process rather than replace it.

One practical use would be to screen the beneficiary and receiving-bank information connected to allotment payments being prepared in the current payment draft, before final approval and bank-file submission.

It could help the company:

• identify payment instructions requiring attention;
• retain screening and review history;
• distinguish unchanged prior candidates from genuinely new information;
• support line-level holds or escalation where the workflow permits; and
• preserve evidence showing what was checked and how the company responded.

The company’s authorised people would still make the operational and compliance decisions.

The bank would still perform its own independent controls.

CrewPayScan could not guarantee that the bank would accept a payment, determine that a payment was legally permitted or prescribe one universal screening policy.

Its intended place is narrower and more practical: helping the company ask and answer its own question before the payment reaches the bank.

A better division of labour

The strongest model is not company screening versus bank screening.

It is company-side controls and bank-side controls, with each party doing the work it is best placed to do.

The bank protects its ability to process the payment through the financial system.

The company protects its ability to release the payment correctly, on time and with a defensible understanding of its decision.

A good bank can be a strong downstream checkpoint.

It should not have to be the company’s first conversation with a potential problem.

So the most useful question is not only:

“Will our bank screen this payment?”

The better question is:

“Before we send this payment to the bank, do we have enough current information to release it—and can we show what supported that decision?”

That remains the company’s question to answer.

Sanctions obligations differ according to jurisdiction, parties and payment. This article discusses operational control design and does not constitute legal advice.