How to design a table for reconciliation A Bank B sends a set of transactions to Bank C every few minutes. Same transactions could be sent multiple times (Bank C should recognize those transactions and should not process them).

At the end of the day, Bank B sends a reconciliation file (that SHOULD contain all transactions that SHOULD BE processed during the day) to Bank C. 

Reconciliation process should provide a report with missing information for set of transaction during the day comparing with the set at the end of the day. Beside that, if any missing transaction is found, it should be processed. 

Should the system use one table for transactions and another one for reconciliation or one single table for both information since the structure of data is the same?
It depends on amount of data and how it will be used. You can have one table for with flag for intraday/COB datasets, then queries that would filter on those flags. After that you'll probably use EXCEPT to get unprocessed transactions. Then you need to keep this data for  2-5-7 years. There may be more requirements. It is OK if you have enough capacity and the only use for this table is one-off reconciliation and then storing data.

However, if you need to run reports on COB data, join it to dimensions, do more reconciliation, enrich with more attributes, send to downstream systems, then you would go for a separate table.